A Question from a PIX noobie

I have a high level 6509 switch connected to a pix and clients that sit behind the PIX, the ACL's on the switch allow for traffic back to the source as tcp "established" but PIX doesnt allow established much to my surprise. So how in chuffs name do we check for the ACK bit in our return packets? And, would there be any reason the PIX doesnt like a packet if it receives it with the ACK bit in the TCP header?

Can anyone assist?

Find more posts tagged with

Comments

dtlokee

The pix uses a stateful packet inspection engine that will track state of the connection, sequence numbers, flags and other parameters, far more sophisticated than checking on the ack bit, so the concept of an "established" parameter isn't needed. The basic concept is when traffic moves through the PIX from a higher to lower security level it creates an entry in the state table only allowing the next return packet in the TCP connection to return (it looks at the ack field to check the ack number) to determine if the traffic is allowed back.

Hope this helps

Pash

dtlokee wrote:

The pix uses a stateful packet inspection engine that will track state of the connection, sequence numbers, flags and other parameters, far more sophisticated than checking on the ack bit, so the concept of an "established" parameter isn't needed. The basic concept is when traffic moves through the PIX from a higher to lower security level it creates an entry in the state table only allowing the next return packet in the TCP connection to return (it looks at the ack field to check the ack number) to determine if the traffic is allowed back.

Hope this helps

Ok thanks dtlokee, that makes more sense.

Pash

dt: one more question mate.

If it uses stateful packet inspection does it need a return ACL for the return packets then? I have a situation where my clients on a seperate vlan cant talk to a server on another vlan at all, our acl's on the core switches are fine, but I reckon the PIX config is wrong. We have an access group in from the vlan with clients and one from the vlan between switch and PIX. I have done something like this on the PIX:

!!!!!!!!!!!!!!!!!!!!
access-list 102 permit tcp 192.168.18.0 255.255.255.0 host 172.17.21.4 eq www
access-list 102 permit tcp 192.168.18.0 255.255.255.0 host 172.17.21.4 eq 443
!!!!!!!!!!!!!!!!!!!!!

access-group 102 in interface outside

!!!!!!!!!!!!!!!!!!!!!!!!!!!
access-list 101 permit tcp host 172.17.21.4 eq www 192.168.18.0 255.255.255.0
access-list 101 permit tcp host 172.17.21.4 eq 443 192.168.18.0 255.255.255.0
!!!!!!!!!!!!!!!!!!!!!!!!!!!

access-group 101 in interface inside

Is the acl lines for 101 even needed then? I would say it is, because unless there is a match on the traffic in from the wire, the packet gets binned.....if it misses everything else the invisiable deny will catch it?

Thanks again,

Ahriakin

You don't need an ACL for the returning traffic (unless it was something that replied using different ports to those sent with, for HTTP/HTTPS shouldn't be an issue). Create your rules on the interface closest to the requester is the general rule of thumb. From your ACL 192.168.18.0/24 is your Outside subnet and 172.17.21.0 is your Inside?. Are you using software 7.x or lower? If 7.x have you enabled Nat-Control ? If so and you aren't using translations, which you shouldn't need to for simply firewalling between 2 private subnets, disable it. If pre 7.x NAT 0 those subnets (with Nat-Control on or as std in previous release you need some translation rule to allow traffic to pass, even if it's a NAT 0 rule to bypass translation it has to be set in stone somewhere, with 7.x and no nat-Control (default) this isn't a problem)

dtlokee

Just to add to what Ahriakin said, by default the pix won't allow traffic to flow from one interface (or vlan) to another interface (or vlan) taht have the same security level, regardless of the access-lists you create, you need the "same-security-traffic permit inter-interface" command to allow the traffic to flow. Other than that you onl need an ACL to allow traffic to go from a lower security level to a higher security level, or if inspection has been disabled or is not available for a the protocol you're using, but for http and https this should not be the case.

Pash

Cheers for that fellas. I need more understanding about how the state table works for PIX, any good white paper links for me?

Pash

Here is what I think is happening, someone is more than welcome to correct me if you think im wrong (which I could be):

The TCP connection originates from the "outside network", it hits the ACL that has the correct network parameters set, the PIX by default changes the TCP sequence number to avoid TCP hijacking, and stores a whole bunch of info the state table. NOW, when the return packet comes back from the destination host on the "inside" network it changes the TCP sequence number again, unwittingly, because it see's it as new traffic that hits the ACL. It passes to the outside network and now flows to the originating host...........oops there is a TCP sequence number mismatch and the host doesn't know what to do, no connection is made.

So my fix is, keeping the ACL on the "outside" interface as is, because, connection originating from the outside network will need an ACL to go past the PIX, the return traffic inside to outside will just flow downhill as is.

Is that it or?

dtlokee

The return traffic should hit the existing information in the state table and not get translated again. Some applications don't like the random sequence numbers which you can turn off by adint "norandomseq" to the nat rule.

Pash

dtlokee wrote:

The return traffic should hit the existing information in the state table and not get translated again. Some applications don't like the random sequence numbers which you can turn off by adint "norandomseq" to the nat rule.

Not sure I understand you dt. I understand that the state table needs to match everything on the packet to go through, but i also understand that higher to lower security level there is no stopping the traffic, so does it even bother checking the state table?

dtlokee

Yes it will look in the state table to see if there's already an entry and use it if one exists (this corresponds to the state of the connection, for TCP the syn bit, but since UDP dosen't have a defined state it will combare to the state table always). The PIX will also track the data stream (based on the inspection configuration) to look for protocols that require secondary connections (like FTP and SCCP) and open the required ports.

Pash

dtlokee wrote:

Yes it will look in the state table to see if there's already an entry and use it if one exists (this corresponds to the state of the connection, for TCP the syn bit, but since UDP dosen't have a defined state it will combare to the state table always). The PIX will also track the data stream (based on the inspection configuration) to look for protocols that require secondary connections (like FTP and SCCP) and open the required ports.

Order checked for our PIX (remember we don;t have NAT enabled so no NAT/PATing is checked before ACL list)

ACL list---->state table

If it hits the ACL, in which case the packets trying to return from the destination hosts will. Then it will create a new entry in the state table?....and unless turned off im guessing it will randomize the TCP seq number (I am not sure if this TCP seq randomiziing is only done if NAT is used? if ithis is the case then i don't understand why it doesnt work), which is stopping our hosts from completeing a handshake?

Thanks for your help dt. If you know of a flowchart for the way PIX handles packet flow, please share with me, as I can;t seem to find one from any white papers.

Pash

dtlokee wrote:

Yes it will look in the state table to see if there's already an entry and use it if one exists (this corresponds to the state of the connection, for TCP the syn bit, but since UDP dosen't have a defined state it will combare to the state table always). The PIX will also track the data stream (based on the inspection configuration) to look for protocols that require secondary connections (like FTP and SCCP) and open the required ports.

Also Because their packets cross a broadcast domain in the shape of a segmented vlan between pix and a core switch, it cant eseentially match anything in the state table then, because it has to match everything, it wouldnt even get past source and destination IP....right?

Pash

Haha, my bad, there was translation from in to out, so without this we coudlnt establish a connection. Truth via debug is always best. However, those lines for inside to out did have to come out still aswell, because they simply werent needed.

Awesome, thanks to Ahriakin and dt.

dtlokee

When "nat control" is on, no traffic can pass without a nat rule, I guess that 's what you're referring to, I'm glad you got it figured out. Truth by debug

nero64

Hi Guys,

I read this post and I have a similar situation with sequencing not matching.

I have the following setup:

ASA-inside(10.17.34.1)

(10.17.34.10)GWRouter(172.31.1.1)---HOST_PC(172.31.1.5)

I have a host hanging of the ASA using 10.17.34.2 and it can ping 172.31.1.5 no problems. I had to do a few things to get that working.

However the HOST_PC cannot ping the 10.17.34.2 host hanging of the ASA.

the packet-tracer command basically tells you what the problem is. The 10.17.34.2 cannot return a echo-reply as there is no matching state entry for it to look to.

Action: drop
Drop-reason: (inspect-icmp-seq-num-not-matched) ICMP Inspect seq num not matched

but I can't work out how to fix it.

I have done the following. Added and ACL to allow echo and echo-reply, put norendomeeq at the end of my nat/pat entries. permitted icmp on and individual basis.

Any ideas on this?

thanks,

nero

nero64

It's ok I solved it:

ciscoasa(config)# sh service-policy

Global policy:
Service-policy: global_policy
Class-map: inspection_default
Inspect: icmp, packet 206, drop 108, reset-drop 0

I had icmp being inspected which was allowing icmp echo replies from the internet but not allowing inside downstream hosts from creating sessions to hosts behind the firewall.