1. Home
  2. Cisco Systems
  3. PIX 501 PAT going to wrong host

PIX 501 PAT going to wrong host

Hi All,

I have a PIX 501 6.3(4) working well except for a problem with PAT entries. They appear to be working like static NAT IP mappings instead of PAT. I need to have requests on 222.333.34.99 on port 3389 forwarded to internal host 192.168.0.2, but it goes to 192.168.0.1. I'm not sure what I am doing wrong. Any help is greatly appreciated!

Addresses are fake (obviously).

name 192.168.0.1 Server01 access-list 100 permit icmp any any echo-reply access-list 100 permit icmp any any time-exceeded access-list 100 permit icmp any any unreachable access-list 100 permit tcp any host 222.333.34.99 eq smtp access-list 100 permit tcp any host 222.333.34.99 eq 4899 access-list 100 permit tcp any host 222.333.34.99 eq 3389 access-list 100 permit tcp any host 222.333.34.99 eq telnet access-list 100 permit tcp any host 222.333.34.99 eq www access-list 100 permit tcp any host 222.333.34.99 eq https access-list 100 permit tcp any host 222.333.34.100 eq 4899 access-list 100 permit tcp any host 222.333.34.100 eq 5023 access-list inside_outbound_nat0_acl permit ip any 192.168.0.224 255.255.255.240 access-list outside_cryptomap_dyn_20 permit ip any 192.168.0.224 255.255.255.240 pager lines 24 logging on logging buffered errors mtu outside 1500 mtu inside 1500 ip address outside 222.333.34.98 255.255.255.248 ip address inside 192.168.0.254 255.255.255.0 ip audit info action alarm ip audit attack action alarm ip local pool vpnpool1 192.168.0.224-192.168.0.239 arp timeout 14400 global (outside) 1 interface nat (inside) 0 access-list inside_outbound_nat0_acl nat (inside) 1 0.0.0.0 0.0.0.0 0 0 static (inside,outside) tcp 222.333.34.99 smtp Server01 smtp netmask

255.255.255.255 0 0 static (inside,outside) tcp 222.333.34.99 telnet Server01 telnet netmask 255.255.255.255 0 0 static (inside,outside) tcp 222.333.34.99 www Server01 www netmask 255.255.255.255 0 0 static (inside,outside) tcp 222.333.34.99 https Server01 https netmask 255.255.255.255 0 0 static (inside,outside) tcp 222.333.34.99 3389 192.168.0.2 3389 netmask 255.255.255.255 0 0 static (inside,outside) tcp 222.333.34.100 4899 192.168.0.100 4899 netmask 255.255.255.255 0 0 static (inside,outside) tcp 222.333.34.100 5023 192.168.0.101 5023 netmask 255.255.255.255 0 0 static (inside,outside) tcp 222.333.34.99 4899 Server01 4899 netmask 255.255.255.255 0 0 access-group 100 in interface outside
Reply to
Concerned Citizen
Loading thread data ...

In article , Concerned Citizen wrote: :I have a PIX 501 6.3(4)

:ip address outside 222.333.34.98 255.255.255.248 :ip address inside 192.168.0.254 255.255.255.0

This probably doesn't affect the problem you are having, but your vpnpool1 address range needs to be "outside" relative to your inside address range. For example you could use

ip local pool vpnpool1 192.168.1.224-192.168.1.239

with the appropriate adjustments to your ACL entries.

Reply to
Walter Roberson

host 192.168.0.2, but it goes to 192.168.0.1.

I don't see how any requests are getting from outside to the inside interface since you have no conduits defined in the config you posted. (this applies to all your internal addresses not just 3389 on

192.168.0.2)

The command static (inside,outside) tcp 222.333.34.99 3389 192.168.0.2

3389 netmask 255.255.255.255 0 0 seems to be correct to translate requests destined to 222.33.34.99 on port 3389 to use the address 192.168.0.2 port 3389 but with no conduit defined, the PIX will block these requests. I don't see how they are going to Server01 with no conduits defined, everything on the outside requesting a session to a device on your inside interface should be getting blocked.

conduit permit tcp host 222.333.34.99 eq 3389 any

This command will allow anyone coming from outside the PIX to go to

192.168.0.2 (after being translated from 222.33.34.99) on port 3389.
Reply to
tholincheck

In article , wrote: :I don't see how any requests are getting from outside to the inside :interface since you have no conduits defined in the config you posted.

conduits are deprecated, long ago replaced with access-group . And the OP -does- have an access-group applied to the outside interface.

The PIX 501 was not introduced until PIX 6.1(1), a full generation after the conduit command was superceeded in PIX 5.1(2) [as I recall], so there are very few good reasons to use 'conduit' on a PIX 501.

If you learned that you must use 'conduit' then your studies were very much out of date.

Reply to
Walter Roberson

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.