07-25-2003 08:04 AM - edited 02-21-2020 12:41 PM
Not sure if I'm just stating the obvious, but here goes...
The problem:
I've discovered that port address translation (pat) can create problems when trying to connect to inside hosts over a vpn tunnel. I've distilled the problem down to the lab setup and startup-config below. It's actually completely independent of vpn.
The symptoms:
1. tftp from client 172.16.0.2 to server address 192.168.0.2 - session established as expected (all traffic destined to 172.16.0.0/24 is explicitly not nat'd)
2. ftp from client 172.16.0.2 to router address 172.16.0.1 - session established as expected (pat static route to 192.168.0.2:21)
3. ftp from client 172.16.0.2 to server address 192.168.0.2 - session not established due to interference from pat
Explanation:
The failure of the session to establish is because the client 172.16.0.2 resets the connection when it receives the SYN/ACK part of the handshake whose source address has been changed by the router. More simply stated, the client 172.16.0.2 sends a connection request to server address 192.168.0.2; upon receiving an acknowledgement from an address other than the original ftp server, the client drops the connection - as it should.
Comments and questions:
We understand what's happening and why it's happening, but should it be happening? It's possible to assign assign acl's to dynamic nat, but it doesn't seem possible to create exclusions for static nat routes. Shouldn't there be a mechanism to apply acl's to static nat/pat routes?
Network topology:
host pc
ip address 172.16.0.2/24
|
|
| ethernet
|
|
806 router
IOS (C806-K9OSY6-M), Version 12.3(1a)
ip address 172.16.0.1/24 (e1)
ip address 192.168.0.1/24 (e0)
|
|
| ethernet
|
|
ftp (pat) and tftp (no pat) server
ip address 192.168.0.2/24
Cisco 806 router config:
ver 12.3
no service pad
!
hostname router01
!
! <nat config>
! <addresses>
ip nat inside source list 110 interface e1 overload
! <port forwarding>
ip nat inside source static tcp 192.168.0.2 20 interface e1 20
ip nat inside source static tcp 192.168.0.2 21 interface e1 21
ip nat inside source static udp 192.168.0.2 20 interface e1 20
ip nat inside source static udp 192.168.0.2 21 interface e1 21
!
! <ip - miscellaneous>
ip route 0.0.0.0 0.0.0.0 e1
ip subnet-zero
!
! <110 - nat addresses>
access-list 110 deny ip 192.168.0.0 0.0.0.255 172.16.0.0 0.0.0.255
access-list 110 permit ip 192.168.0.0 0.0.0.255 any
!
interface ethernet0
ip address 192.168.0.1 255.255.255.0
ip tcp adjust-mss 1452
hold-queue 32 in
hold-queue 100 out
ip nat inside
no shutdown
!
interface ethernet1
ip address 172.16.0.1 255.255.255.0
ip tcp adjust-mss 1452
ip nat outside
no shutdown
!
interface dialer0
shutdown
line con 0
exec-timeout 120 0
stopbits 1
line vty 0 4
exec-timeout 120 0
length 0
scheduler max-task-time 5000
end
07-31-2003 06:57 AM
Here is my 2 cents on IPSec over PAT. It's not that IPSec and Pat never go together. However, to make them work you need to be careful abouta couple of things. As an example, some PAT devices use the UDP source port 500 for all IKE sessions. The first session is allowed just fine but as soon as the second connection is brought up, the first is torn down. The way to get around this is to use a PAT device that uses a unique UDP source ports for each additional session.
If you are interested in digging deeper, you should refer to http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a0080110bca.html.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide