Traffic needs to leave internal and come back in-but does not

jeff.alston · ‎07-24-2003

PIX 6.31. Two interfaces: inside/outside. Config is insdie>pix>rtr>inside. No requirement or desire to do NAT and translation should not be on. Access lists are pretty much allowing all IP to flow between the networks. Traffic for one client on the inside must register on a NetBIOS name server on the outside and the registration replies need to come back internal. They don't. Replies from the WINS just stop at the outside interface of the PIX. Why??? I watch the individual packets flow just as described and die. Debugging tells me nothing...at least as I am trying it.

mhoda · ‎07-24-2003

Hello,

PIX Algorithm requires that you have to have NAT from inside to outside connection and static for outside to inside connection. Looks like you haven't turned off the nat for outbound connection. Please execute the followings and see if that fixes the problem -

nat (inside) 0 0

clear xlate

Regards,

Mynul

jeff.alston · ‎07-27-2003

No dice. Still seeing the same behavior. PIX will see into the inside and outside networks with PING (since we have it on for testing). But devices respective of each side won't see across. Strange thing is, I see connections being built from the outside in for this particular operation. The other item is that I seek packets come in from internal, pass through the pix, the router, hit the server they need to, and see the replies travel back to the internal net. They stop, it appears, at the outside interface of the pix, yet I see the connection built???

jboyer · ‎07-28-2003

Ping can be enabled to and from the pix with "icmp permit any any" but access-lists require an associated access-group command to apply the access list to the appropriate interface, make sure you have applied the access-list to the outside interface. Also, if you can capture the packets outside the firewall look for icmp packets from the pix stating "administratively filtered" This indicates the pix access policy is denying the packets.

jeff.alston · ‎07-30-2003

Have to wait until the weekend so I don't tick too many users off. What about subnetting? I have an entire Class B. I use a bunch of the subnets throughout. In my routing and rules on the PIX, I treat it as 172.16.0.0 255.255.0.0 and let it go. Does not seem to be a problem...will it?

l.mourits · ‎07-30-2003

Hi,

If you have a class B on your inside, and use a subnet out of this same class B, there might be a change that you made an overlapping NAT statement within your config, which can give unexpected behaviour.

Operation if a returning packet arrives at the outside interface is this:

- returning packet is recieved

- if it is an existing flow accept packet and forward

Some UDP portnumbers (and also some TCP portnumbers) are not handled by the ASA and never get a connected state. This is also the case with ICMP (that is the reason why you always have to have a ACL or conduit permitting returning trafic for ICMP Ping)

It could be that this UDP port gets no connected state, and it is arriving on the outside interface, then there has to be an ACL bounded to the interface which permits this returning traffic.

So, if you can test it out to see if it does work with an ACL which permits this traffic, then it gets no connected state. If it still does not return when the ACL permits it, you probably have an overlap on NAT.

Hope this helps.

Leo

jeff.alston · ‎07-31-2003

I think I am way too far down in the weeds. If the PIX requires translation and an access list or conduit, how do I set up translation with no NAT to give the PIX something it will be happy with? Will a couple globals for each net and some NAT command I obvioulsy don't know get me there?

TIA

jboyer · ‎08-04-2003

The "NAT 0" command translates the address to the outside without changing the address. You can also make a static entry with the same inside and outside address.