PIX --------- Server 1 | --------- Server 2 | | Switch 1 ------------ Multiple Hosts ------------ Host AS500
Currently the PIX has static statements and access-list which allow SSH from the outside into Server 1 and Server 2. When one tries to ssh into
216.X.X.A which is the public IP on the PIX. The PIX sends you too Server 1. When you SSH into 216.X.X.B. The PIX sends you too Server 2. What I need is the PIX to allow SSH into the AS500 host which is located behind the PIX using SSH. How can I set this up?
On the PIX, give the command show static That will show you the existing static configuration commands that make the connection between 216.X.X.A and Server 1, or
216.X.X.B and Server 2. You'll need another one of those commands except modified for 216.X.X.C and the AS500 host.
Then on the PIX, show access-group and find the access-group entry that is marked as being "in interface outside". The name between the token 'access-group' and the 'in' will be the name of an access-list. For the purposes of this discussion I'll call that Out2In_ACL. show access-list followed by that name (e.g., show access-list Out2In_ACL ) and you will see an entry about permit tcp any host 216.X.X.A eq 22 (that is, the ssh port) and another similar for 216.X.X.B . You need to add another entry like those for 216.X.X.C .
Note, though, that if you simply go into configuration mode and command
access-list Out2In_ACL permit tcp any host 216.X.X.C eq 22
then that will go at the *bottom* of the access-list, and if there happens to be a 'deny' statement above that point on the list, that deny statement might happen to block some of the traffic you want. You need to get the new entry into the right location in the list; the methods of doing that are dependant on the software version and I don't have time (or interest) to describe them.
After you have put in the new access-list entry and the new static entry, give the command clear xlate Test the result, and if it works, then command write memory in order to save the changes to be known at the next reboot.
Each of these versions would require that the client request connection to port 4000 but that the server on AS500 would still be on port 22. If you want to change the server to also be on 4000, then in the static statements where you see the 22, repace it with 4000.
You haven't given us enough to work with here. *What* error? And which PIX version? And are you trying to work with the interface IP or with a different IP?
The error is that I cannot connect to the ip address 216.X.X.A using port 4000. The remote host just keeps on trying to connect and nothing. The PIX version is > Cisco PIX Firewall Version 6.3(5)
For this example let just say I am trying to enable telnet instead of ssh. I know thats not a good idea however, it's just to see if this works correctly. Because if I want to use with the host behind the firewall I must upgrade the IOS for one that has the SSH feature. Below is a copy of the PIX config.
PIX Version 6.3(5) interface ethernet0 100full interface ethernet1 100full nameif ethernet0 outside security0 nameif ethernet1 inside security100 enable password XXXXXXXXXXXX encrypted passwd XXXXXXXXx encrypted hostname pixfirewall domain-name xxxx.com clock timezone EST -5 clock summer-time EDT recurring fixup protocol dns maximum-length 512 fixup protocol ftp 21 fixup protocol h323 h225 1720 fixup protocol h323 ras 1718-1719 fixup protocol http 80 fixup protocol pptp 1723 fixup protocol rsh 514 fixup protocol rtsp 554 fixup protocol sip 5060 fixup protocol sip udp 5060 fixup protocol skinny 2000 fixup protocol smtp 25 fixup protocol sqlnet 1521 fixup protocol tftp 69 names access-list 101 permit ip 10.1.1.0 255.255.255.0 10.1.2.0 255.255.255.0 access-list allow_inbound deny ip 59.124.0.0 255.252.0.0 any access-list allow_inbound deny ip host 24.71.105.183 any access-list allow_inbound deny ip host 163.27.116.133 any access-list allow_inbound deny ip host 218.189.179.82 any access-list allow_inbound deny ip host 84.60.164.161 any access-list allow_inbound deny ip host 222.128.34.89 any access-list allow_inbound deny ip host 202.64.47.108 any access-list allow_inbound permit tcp any interface outside eq smtp access-list allow_inbound permit tcp any interface outside eq pop3 access-list allow_inbound permit tcp any interface outside eq www access-list allow_inbound permit icmp any any source-quench access-list allow_inbound permit icmp any any echo-reply access-list allow_inbound permit tcp any interface outside eq ssh access-list allow_inbound permit tcp any host 216.X.X.B eq www access-list allow_inbound permit tcp any host 216.X.X.B eq ssh access-list allow_inbound permit tcp any host 216.X.X.B eq h323 access-list allow_inbound permit tcp any host 216.X.X.B eq 5060 access-list allow_inbound permit tcp any interface outside eq pptp access-list allow_inbound permit gre any interface outside access-list allow_inbound permit tcp any interface outside eq 3000 access-list allow_inbound permit tcp any interface outside eq 13492 access-list allow_inbound permit udp any interface outside eq 13492 access-list allow_inbound permit udp any interface outside eq 49153 access-list allow_inbound permit tcp any interface outside eq 49153 access-list allow_inbound permit tcp any interface outside eq 10240 access-list allow_inbound permit tcp any interface outside eq 10241 access-list allow_inbound permit tcp any interface outside eq 10242 access-list allow_inbound permit udp any interface outside eq 10240 access-list allow_inbound permit udp any interface outside eq 10241 access-list allow_inbound permit udp any interface outside eq 10242 access-list allow_inbound permit tcp any interface outside eq 41170 access-list allow_inbound permit udp any interface outside eq 41170 access-list allow_inbound permit tcp any interface outside eq 4662 access-list allow_inbound permit tcp any interface outside eq 4000 access-list deny_outbound deny tcp any host 63.236.240.73 eq https access-list deny_outbound deny tcp any host 209.202.9.7 eq https access-list deny_outbound deny tcp any host 63.236.240.73 eq www access-list deny_outbound deny tcp any host 66.28.235.59 eq www access-list deny_outbound deny tcp host 10.1.1.253 host 216.178.32.49 eq www access-list deny_outbound deny tcp host 10.1.1.253 host 216.178.32.48 eq www access-list deny_outbound deny tcp host 10.1.1.253 host 216.178.32.50 eq www access-list deny_outbound deny tcp host 10.1.1.253 host 216.178.32.51 eq www access-list deny_outbound permit ip any any access-list deny_outbound permit esp any any access-list deny_outbound permit gre any any access-list do_not_nat permit ip 10.1.1.0 255.255.255.0 10.1.2.0
telnet to which address? You cannot telnet to the outside interface IP of the PIX, even if you have set up port forwarding from the interface to some internal host. The PIX *specifically* blocks telnet to the outside interface. (The only exception is if the traffic is within a VPN tunnel.)
This restriction on the PIX does not apply if you are using any destination address other than the PIX outside interface address: you are allowed to configure the PIX to allow telnet to public address and have that sent on to the host.
The IOS of what? PIX doesn't use IOS: it uses an operating system named Finesse but more commonly called "PIX OS". And ssh to the PIX has been supported on all PIX for a number of releases, including
6.3(5). You do not need to upgrade your PIX to be able to ssh to the PIX itself (e.g., to manage the PIX); you do, though, need to use the "ca generate" command (with appropriate parameters) to generate an RSA key, and then use the "ca save all" command to save that RSA key to permanent memory.
Personally, I don't allow source-quench through: source-quench packets have no authentication information, so they can be used as a small Denial of Service against your machines.
Those two lines are likely to fail for you. gre does not have any port numbers, and so cannot be used with Port Address Translation like TCP and UDP can be. PIX 6.x does not provide any mechanism to forward gre packets to a specific inside host -- there is, for example, NO
If your intention was to allow pptp connections to terminate -at- the PIX, then you do not need to allow to permit pptp or gre in your access-list as the PIX will automatically open them to support configured vpdn
If I recall correctly which thread this is, you wanted to be able to ssh to an alternate port (4000) on the PIX and have that go to a different machine. If so then the line you configured above should be fine.
esp and gre are subsets of ip, so those last two lines are redundant. Also if the idea was to permit VPN tunnels terminating -at- the PIX (rather than VPN that passes -through- the PIX) then you do not need these, as the PIX will automatically permit that traffic if it needs it.
You should allow icmp time-exceeded and icmp unreachable to the outside interface: otherwise icmp packets coming back for traffic that was PAT'd to the outside interface address will not make it through. The permit icmp that you have in the access-list applied to the outside interface does not affect icmp traffic that has the PIX outside IP as its destination, even if that destination IP is only there because of PAT.
Those are good.
That's not really necessary: if you have traffic from the inside that has a source IP address that is not in the 10.1.1/24 range, then something is misconfigured or rogue, and the traffic should probably not be permitted to go outside.
255.255.255.255 0 0
Related to the discussion above about telnet: that discussion does not apply when the target port is not the telnet port. The above line should indeed redirect outside interface port TCP 4000 to the telnet port of
10.1.1.251
Most people should have 'poll' on the end of their snmp-server statements. snmp-server host inside 10.1.1.23 poll
I recommend that you change your
logging trap notifications
to
logging trap debug
and look at your syslog on 10.1.1.23 as you make the attempt to telnet in through port 4000.
Sorry that I took a while to get back. Below is the output from the syslog server. The IP address 71.X.X.174, is where the telnet connection was issued to the PIX.
402106: Rec'd packet not an IPSEC packet. (ip) dest_addr= 216.X.X.85, src_addr= 71.X.X.174, prot= tcp
402106: Rec'd packet not an IPSEC packet. (ip) dest_addr= 216.X.X.85, src_addr= 71.X.X.174, prot= tcp
305012: Teardown dynamic UDP translation from inside:10.1.1.2/4871 to outside:216.X.X.85/32189 duration 0:00:32
305012: Teardown dynamic TCP translation from inside:10.1.1.2/4247 to outside:216.X.X.85/27789 duration 0:00:32
302014: Teardown TCP connection 6367571 for outside:67.158.75.133/6346 to inside:10.1.1.23/3313 duration 0:55:29 bytes 38069 FIN Timeout
305012: Teardown dynamic TCP translation from inside:10.1.1.23/3313 to outside:216.X.X.85/27625 duration 0:55:32
305012: Teardown dynamic UDP translation from inside:10.1.1.252/2683 to outside:216.X.X.85/32190 duration 0:00:31
402106: Rec'd packet not an IPSEC packet. (ip) dest_addr= 216.X.X.85, src_addr= 71.X.X.174, prot= tcp
710005: UDP request discarded from 10.1.1.23/138 to inside:10.1.1.255/netbios-dgm
302015: Built outbound UDP connection 6367949 for outside:66.214.114.23/21236 (66.214.114.23/21236) to inside:10.1.1.23/27867 (216.254.64.85/30380)
710005: UDP request discarded from 10.1.1.252/7500 to inside:10.1.1.255/7500
710005: UDP request discarded from 10.1.1.252/7500 to inside:10.1.1.255/7500
710005: UDP request discarded from 10.1.1.252/7500 to inside:10.1.1.255/7500
Walter Robers> > >For this example let just say I am trying to enable telnet instead of
You would get that message if you tried to connect to the telnet port of a PIX with outside address 216.X.X.85 .
You would not, however, get that message if you configure telnet passing through on a different port (e.g., 4000) and connect to that.
Your earlier configuration postings did show a translation on port 4000; is it possible that whatever client you were using was connecting to the default port (23) instead of to 4000 ?
These are the errors which I got when I tried again to telnet into the PIX using port 4000. I used Hyperterminal on the remote host, and changed the port number to 4000 and entered the IP address 216.X.X.85. What am I doing wrong?
2006-09-17 00:09:24 Local4.Info 10.1.1.1 Sep 16 2006 12:03:07: %PIX-6-302013: Built inbound TCP connection 6440580 for outside:71.X.X.174/50439 (71.X.X.174/50439) to inside:10.1.1.251/23 (216.X.X.85/4000)
2006-09-17 00:09:38 Local4.Info 10.1.1.1 Sep 16 2006 12:03:21: %PIX-6-302014: Teardown TCP connection 6440257 for outside:71.X.X.174/50438 to inside:10.1.1.251/23 duration 0:02:01 bytes
0 SYN Timeout
Walter Robers> > >Sorry that I took a while to get back. Below is the output from the
Those look fine in themselves: they indicate that the PIX accepted the connection and forwarded the addressed 216.X.X.85 port 4000 on to 10.1.1.251 port 23, but that the PIX did not see any response from 10.1.1.251 within 2 minutes and so timed out the connection.
This could indicate that 10.1.1.251 does not have a default route or gateway set so that the packets are not getting back to the PIX.
But the time stamps are odd. The first timestamp on the line is the time that the logger received the message, and the second timestamp on the line is the time registered on the PIX when it sent the message.
First off, notice that the elapsed time on both the PIX and the logger was only 14 seconds, not 2 minutes.
Secondly, notice that the timestamps on the two are way out of sync, with the logger being 12 hours, 6 minutes and 17 seconds ahead.
12 hours could be accounted for if you happen to be 12 hours off of GMT and your PIX is set for GMT, but the 6 minutes and 17 seconds implies that either the clocks are not synchronized or else that you have a *very* large internal network delay.
Have you tried setting up 'ntp server' on the PIX? (Have you tried setting up an ntp client on your logging machine) ?
No I have not setup a ntp server on the PIX, and I have not tried setting up an ntp client on the logging machine. The clocks have not been set on the PIX or on the logging host. Regarding the packets from the PIX not reaching the host 10.1.1.251 which is a Router. Packets from the PIX are reaching the router. If I issue a ping from the PIX to the Router I get a response and vice versa. Also, in the routing table the Router has a route to the 10.1.1.0 network where the PIX resides.
Walter Robers> > >These are the errors which I got when I tried again to telnet into the
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.