Simple NAT trouble

[jroyster]

Been having some trouble on a 525 with 6 interfaces.

web (sec30)---pix---partner (sec60)

server is off web interface (172.23.x.x), partner contains networks in the 172.21.0.0 range.

This is an "internal" firewall so we don't want addresses to actually be translated, just stay the same.

static (partner, web) 172.21.0.0 172.21.0.0

the translation is built but for some reason the log messages on the pix say "built inbound connection from 172.23.x.x (web) to 172.21.x.x (partner)"

it looks like the 2nd packet of the tcp handshake is triggering the connection instead of what I "think" should be happening....built outbound connection from 172.21.x.x (partner) to 172.23.x.x (web)

any clues? this should be fairly simple but the config on the pix is so horrendeously complicated that its hard to troubleshoot.

there is a router on the partner side that I've done some packet debugging on and can verify that the partner inteface is indeed receiving the first tcp-syn. but for some reason the connection is built as inbound?

thanks for any tips.

[revangelista]

You actually have answered your own question with: "This is an "internal" firewall so we don't want addresses to actually be translated, just stay the same."

Therefore, use 'nat 0' which bypassess the NAT'ing of IP addresses. Adding a corresponding ACL will limit the traffic. Clearing the xlate after updating your commands should ensure better results.

[jroyster]

thanks for the tip. I added a nat (partner) 0 networks, took out the statics and cleared the xlate table.

Now I'm getting "built outbound connection for web:172.23.x.x to partner:172.21.x.x"

something fishy is going on. now the handshake looks like this

client - syn

server - syn ack

client - reset

-edit- hmmm. By looking at the packets on the partner side the server is ACKing a different sequence number thant the client provided. somehow TCP isn't completing.

<---banging my head.

[ehirsel]

Can you tell me how the acl is defined that you refer to in your nat (parnter) 0 statement?

What version of pix code are you running? The 6.2 and hihger contain what I think is a better troubleshooting tool than packet debugs: the capture statement; it is similar to the unix tcpdump tool. I don't know if v6.0 and v6.1 containt the capture command or not.

[ehirsel]

Here is a snippet from the pix 6.3 doc with regards to a build inbound/outbound message:

302013

Error Message %PIX-6-302013: Built {inbound|outbound} TCP connection number for interface_name:real_address/real_port (mapped_address/mapped_port) to interface_name:real_address/real_port (mapped_address/mapped_port) [(user)]

Explanation A TCP connection slot between two hosts was created.

Where:

connection number is a unique identifier.

interface, real_address, real_port identify the actual sockets.

mapped_address, mapped_port identify the mapped sockets.

user is the AAA name of the user.

If inbound is specified, then the original control connection was initiated from the outside. For example, for FTP, all data transfer channels are inbound if the original control channel is inbound. If outbound is specified, then the original control connection was initiated from the inside.

Recommended Action None required.

Note that the inbound means that the connection originated from the outside, not from your web server. The first set address/interface is where the packet is destined to.

I believe that you had the correct config earlier with the static; however the nat (intferface) 0 access-list command can do the same thing.

You mentioned that there is a router in the partner network. Do you know if the partner net is running ios firewall feature set? I wonder if the issue is with some type of asymetric routing on the partner net that is causing a firewall over there to drop the packets.

[jroyster]

this is just plain weird.

here's a snippit of the logs:

Built local-host lenox:172.21.23.119

2004-04-14 13:42:27 Auth.Info 172.21.8.3 Apr 14 2004 13:22:24: %PIX-6-305009: Built dynamic translation from lenox:172.21.23.119 to web:172.21.23.119

2004-04-14 13:42:27 Auth.Info 172.21.8.3 Apr 14 2004 13:22:24: %PIX-6-302013: Built outbound TCP connection 218789311 for web:172.23.2.7/80 (172.23.2.7/80) to lenox:172.21.23.119/1872 (172.21.23.119/1872)

it says its building an outbound connection from the server to the client. shouldn't it be the other way around given the security levels?

And I've also verified with sniffers that the server is acking a different sequence number in stage 2 of the tcp handshake...hence TCP never finishes. Its not that packets are dropped...its that the replies are acking the wrong seq number. The replies are being passed thru the firewall.

What in the world would cause TCP to break down like this?

To answer the questions:

The nat 0 command has 172.21.23.0/24 as the source (this is the net we're testing from on the partner side)

[jroyster]

it is starting to look like some kind of assymetric routing problem.

But I still can't figure out why the server is acking the packet with the wrong seq#.

[jroyster]

sure enough. assymetrical routing. some yahoo had a whole bunch of static routes defined on the web server itself. All the networks and supernets on the partner side were following a different path than the firewall.

works fine now.