Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

NAT+VPN Issue

I have the following scenario:

Host1-Firewall1-VPNRouter1-(IPSEC TUNNEL)-VPNRouter2-Firewall2-Host2

Firewall1 is a non IOS non PIX

VPNRouter1 is IOS

VPNRouter2 is IOS

Firewall2 is PIX

Firewall1 is NAT'ing 1-1 the address of Host1.

VPNRouter1 is NAt'ing both Host1 and Host2 because both networks are overlapping.

Firewall2 is not performing NAT and has a rule permitting traffic from Host1 to Host2.

When Host1 tries to open an FTP session to Host2 (its NAT'ed address) the tunnels creates and the Firewall2 allos the connection. But the FTP does not opens. The only message I see is the following:

302001: Built inbound TCP connection 103 for faddr 10.96.111.65/5840 gaddr 10.96

.108.65/21 laddr 10.96.108.65/21

302002: Teardown TCP connection 103 faddr 10.96.111.65/5840 gaddr 10.96.108.65/2

1 laddr 10.96.108.65/21 duration 0:00:00 bytes 0 (TCP Reset-O)

What is wierd is that if I try any connection that is succesfull I get the same message but instead of a (TCP Reset-O) I get a (TCP FINs) message.

If someone has seen this message before. I would really appreciate it. I'm thinking that probablt the doble NAT in both Firewall1 and VPNRouter1 may have something to do with the problem. BTW I did a no fixup protocol ftp 21, just in case but it doesn't work.

Thanks

Gabriel

1 REPLY
Cisco Employee

Re: NAT+VPN Issue

TCP-Reset-O means the PIX tore down this session cause it saw a TCP RST from teh Outside interface (or at least, the lower security interface of the two interfaces this traffic flow is going over).

I have no idea where these addresses are or which interfaces are which in your two PIX, or even which PIX this message appears on, so it's impossible for me to tell you much more than that I'm afraid. Basically the PIX sees a TCP RST, so see if you can determine why the server or the client (I'm not sure which one is sending it here, but you should be able to) is sending it out.

96
Views
0
Helpful
1
Replies