topic Re: PIX blocking unspecified traffic in Network Security

PIX blocking unspecified traffic

chrisgray1 — Mon, 11 Mar 2019 13:44:49 GMT

I am no security expert but it appears that our pix firewall is blocking traffic from a higher security level interface to the outside interface when there are no access-lists specifically blocking this traffic.

a ping from 217.nn.n.164 to a host on remote subnet 10.0.32.1 accross an IPSEC VPN tunnel which does not terminate on this firewall is unsuccessful. I have determined that the traffic is entering our inside interface and is not reaching the outside interface.

access-list sniffer line 1 extended permit ip host 217.nn.n.164 host 10.0.32.1 log informational interval 300 (hitcnt=123) 0x70a2c4d4

capture sniffercap2 access-list sniffer interface outside

capture sniffercap access-list sniffer interface vlan309-e3

LIV-SVR-01(config)# sh capture sniffercap

10 packets captured

1: 14:25:26.759665 217.nn.n.164 > 10.0.32.1: icmp: echo request

2: 14:25:28.259660 217.nn.n.164 > 10.0.32.1: icmp: echo request

3: 14:25:29.759650 217.nn.n.164 > 10.0.32.1: icmp: echo request

4: 14:25:31.259691 217.nn.n.164 > 10.0.32.1: icmp: echo request

5: 14:25:32.759619 217.nn.n.164 > 10.0.32.1: icmp: echo request

LIV-SVR-01(config)# sh capture sniffercap2

0 packet captured

0 packet shown

I have been looking into this all yesterday and am at a loss as to why this is happening.

The route to the 10.0.32.0 network is in place also and I know it is valid because other routes such as to 10.184.0.0, another customer subnet are routed fine out this interface.

S 10.0.32.0 255.255.255.0 [1/0] via 217.77.0.73, outside

If anyone can help me out on this issue I would be grateful.

Re: PIX blocking unspecified traffic

andrew.prince — Tue, 16 Sep 2008 12:51:39 GMT

Chris,

It actually looks like from a lower interface to a higher, not the other way around....I assume the 10.x is on the inside and the 217.x is on the outside?

There is an implicit permit all from a higher to lower interface and implicit deny from a lower to a higher interface.

HTH>

Re: PIX blocking unspecified traffic

chrisgray1 — Tue, 16 Sep 2008 13:14:21 GMT

Hi, Andrew thanks for the response. Actually we have a block of 15 class C public IP networks for public addressing within our datacentre. The 10.0.32.0 network is a subnet within the customers private network and I have setup a new VPN tunnel from there site to a 26k router which established at phase 2 but they couldn't reach their server within the DC from this subnet even though I am 100% sure the VPN is allowing return traffic from the 217.nn.n.128/26 to 10.0.32.0/24.

The routing is fine between the 26k and this server subnet. With our main shared services firewall in between who's vlan309-e3 interface is the default gateway address for this internal subnet.

regards

Chris

Re: PIX blocking unspecified traffic

andrew.prince — Tue, 16 Sep 2008 13:17:06 GMT

Chris,

OK that makes sense and is a lot clearer - can you provide the config for the VPN, also the output of the below:-

show crypto isakmp sa

show crypto ipsec sa

Re: PIX blocking unspecified traffic

chrisgray1 — Tue, 16 Sep 2008 13:19:33 GMT

To answer your question the higher security interface is the 217.nn.n..128/26 interface vlan309-e3 and route to the 10.0.32.0 network is via the outside interface.

thanks

Chris

Re: PIX blocking unspecified traffic

chrisgray1 — Tue, 16 Sep 2008 13:25:33 GMT

Actually, we've had to bring it down again because the customer is for some reason migrating from one VPN to another. When we brought up the new VPN which is not conflicting because their source address is doing PAT from the address 192.168.253.1 we found that they could not reach this server subnet.

They have had to manually alter the routing to force it out of the old VPN again which is now back up and passing traffic but obviously because they are using PAT the traffic is not routed back to the 10.0.32.0 from our perspective.

To me the issue appears to me to be with the firewall because if I do the same sniffer trace to another of their subnets 10.183.0.0 and do a ping from the server to 10.183.0.1 I see that the traffic is captured on both interfaces of the PIX.

Re: PIX blocking unspecified traffic

chrisgray1 — Tue, 16 Sep 2008 14:13:44 GMT

Based on another post I've found out about the packet-traceer command and have run it on the PIX that I am think is causing this issue. Here is the output which appears to DROP the packets due to (no-adjacency) No valid adjacency, can anyone advise on this?

thanks.

LIV-SVR-01# packet-tracer input vlan309-e3 tcp 217.nn.n.164 citrix-ica 10.0.32.1 1024

Phase: 1

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 2

Type: FLOW-LOOKUP

Subtype:

Result: ALLOW

Config:

Additional Information:

Found no matching flow, creating a new flow

Phase: 3

Type: UN-NAT

Subtype: static

Result: ALLOW

Config:

static (inside,vlan309-e3) 10.0.0.0 10.0.0.0 netmask 255.255.0.0

nat-control

match ip inside 10.0.0.0 255.255.0.0 vlan309-e3 any

static translation to 10.0.0.0

translate_hits = 0, untranslate_hits = 196185

Additional Information:

NAT divert to egress interface inside

Untranslate 10.0.0.0/0 to 10.0.0.0/0 using netmask 255.255.0.0

Phase: 4

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group acl_vlan309 in interface vlan309-e3

access-list acl_vlan309 extended permit ip 217.nn.n.128 255.255.255.192 any

Additional Information:

Phase: 5

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 6

Type: FOVER

Subtype: standby-update

Result: ALLOW

Config:

Additional Information:

Phase: 7

Type: NAT-EXEMPT

Subtype: rpf-check

Result: ALLOW

Config:

Additional Information:

Phase: 8

Type: NAT

Subtype: host-limits

Result: ALLOW

Config:

static (vlan309-e3,outside) 217.nn.n.128 217.nn.n.128 netmask 255.255.255.192

nat-control

match ip vlan309-e3 217.nn.n.128 255.255.255.192 outside any

static translation to 217.n.n.128

translate_hits = 54334, untranslate_hits = 664114

Additional Information:

Phase: 9

Type: NAT

Subtype: rpf-check

Result: ALLOW

Config:

static (inside,vlan309-e3) 10.0.0.0 10.0.0.0 netmask 255.255.0.0

nat-control

match ip inside 10.0.0.0 255.255.0.0 vlan309-e3 any

static translation to 10.0.0.0

translate_hits = 0, untranslate_hits = 196187

Additional Information:

Phase: 10

Type: NAT

Subtype: host-limits

Result: ALLOW

Config:

static (inside,outside) 10.0.0.0 10.0.0.0 netmask 255.255.0.0

nat-control

match ip inside 10.0.0.0 255.255.0.0 outside any

static translation to 10.0.0.0

translate_hits = 0, untranslate_hits = 84726

Additional Information:

Phase: 11

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 12

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 309238390, packet dispatched to next module

Result:

input-interface: vlan309-e3

input-status: up

input-line-status: up

output-interface: inside

output-status: up

output-line-status: up

Action: drop

Drop-reason: (no-adjacency) No valid adjacency

Re: PIX blocking unspecified traffic

chrisgray1 — Tue, 16 Sep 2008 14:25:27 GMT

Hopefully I'm onto something here. The packet-tracer command output is below showing packets from the same address towards the other customer subnet 10.183.0.0 that gets through ok, it says this is allowed.

LIV-SVR-01# packet-tracer input vlan309-e3 tcp 217.nn.n.164 citrix-ica 10.183.0.1 1024

Phase: 1

Type: FLOW-LOOKUP

Subtype:

Result: ALLOW

Config:

Additional Information:

Found no matching flow, creating a new flow

Phase: 2

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in 10.183.0.0 255.255.0.0 outside

Phase: 3

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group acl_vlan309 in interface vlan309-e3

access-list acl_vlan309 extended permit ip 217.nn.n.128 255.255.255.192 any

Additional Information:

Phase: 4

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 5

Type: FOVER

Subtype: standby-update

Result: ALLOW

Config:

Additional Information:

Phase: 6

Type: NAT

Subtype:

Result: ALLOW

Config:

static (vlan309-e3,outside) 217.nn.n.128 217.nn.n.128 netmask 255.255.255.192

nat-control

match ip vlan309-e3 217.nn.n.128 255.255.255.192 outside any

static translation to 217.nn.n.128

translate_hits = 54361, untranslate_hits = 664335

Additional Information:

Static translate 217.nn.n.128/0 to 217.nn.n.128/0 using netmask 255.255.255.192

Phase: 7

Type: NAT

Subtype: host-limits

Result: ALLOW

Config:

static (vlan309-e3,outside) 217.nn.n.128 217.nn.n.128 netmask 255.255.255.192

nat-control

match ip vlan309-e3 217.nn.n.128 255.255.255.192 outside any

static translation to 217.nn.n.128

translate_hits = 54361, untranslate_hits = 664335

Additional Information:

Phase: 8

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 9

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 309255990, packet dispatched to next module

Phase: 10

Type: ROUTE-LOOKUP

Subtype: output and adjacency

Result: ALLOW

Config:

Additional Information:

found next-hop 217.nn.0.73 using egress ifc outside

adjacency Active

next-hop mac address 0013.7fc3.f680 hits 163414

Result:

input-interface: vlan309-e3

input-status: up

input-line-status: up

output-interface: outside

output-status: up

output-line-status: up

Action: allow

Re: PIX blocking unspecified traffic

chrisgray1 — Tue, 16 Sep 2008 15:08:11 GMT

I am stuck at this point as I don't know why the PIX dops this traffic. If anyone can advise, I'd be very grateful.

thanks

Chris

Re: PIX blocking unspecified traffic

andrew.prince — Tue, 16 Sep 2008 15:10:51 GMT

Chris,

Sorry - was dealing with a work issue. OK - read your previous posts, any chance you can post a sanitised config relating to this?

Re: PIX blocking unspecified traffic

chrisgray1 — Tue, 16 Sep 2008 15:19:06 GMT

Hi Andrew,

The PIX config is really quite large, do you mean the full pix config?

BTW the n actually corresponds to the same single digit everywhere.

thanks

Chris

Re: PIX blocking unspecified traffic

andrew.prince — Tue, 16 Sep 2008 15:21:25 GMT

Chris,

Just post the:-

1) Interesting traffic acl

2) no-nat ACL

3) Crypto entry

Re: PIX blocking unspecified traffic

chrisgray1 — Tue, 16 Sep 2008 15:34:04 GMT

Hi Andrew.

1) The VPN is not setup on this PIX the PIX is mean't to be forwarding traffic to 10.0.32.0 over to the 26k router which is also here onsite. The VPN is setup on the 26k router and I can confirm that on the 26k router when I debug IP packet with an ACL to capture traffic from the server 217.nn.n.164 to 10.0.32.0 nothing comes through from the PIX. Whereas when I debug IP packet from this server to 10.183.0.1, I see this traffic come through.

2) Here is the no-nat ACL on the PIX

access-list no-nat extended permit ip 217.77.0.0 255.255.240.0 any

access-list no-nat extended permit ip 10.0.0.0 255.0.0.0 any

access-list no-nat extended permit ip 172.16.0.0 255.240.0.0 any

access-list no-nat extended permit ip 192.168.0.0 255.255.0.0 any

3) There is no crypto entry on the PIX for this VPN.

So from my perspective I'm looking for a reason why the traffic is not forwarded by the PIX to the 26k - the VPN router and is instead dropped by the PIX. Would you agree that this is the issue or do you need to see the 26k VPN setup? as I don't believe this is the problem.

thanks

Chris

Re: PIX blocking unspecified traffic

andrew.prince — Tue, 16 Sep 2008 17:18:04 GMT

Chris,

Are you allowing the correct protocols and tcp/udp ports thru the PIX to be able to terminate the VPN on the 26xx.

From your description - VPN traffic should be passin THRU the pix to terminate on the 26xx, is this correct?

Check your NAT statements - alsi check that the remote end device is/or not using NAT-T, as the ASA does understand VPN pass-thru?

HTH>

Re: PIX blocking unspecified traffic

maltuna — Wed, 17 Sep 2008 00:07:03 GMT

Late to this, and confused, but trying to help anyways...

I was thinking:

host (217.x.x.164) -> (217.x.x.x) ASA (217.77.0.?) -> (217.77.0.73) 26XX router -> VPN tunnel -> (10.0.32.1) endpoint

where packet only gets as far as:

host -> ASA -> (dropped)

Is this not correct?

Ok, if that is correct, what is the IP network between the 26XX router and the ASA? Probably doesn't matter, but something weird is going on here...

Anyways, you said that your routing on the ASA is correct:

S 10.0.32.0 255.255.255.0 [1/0] via 217.77.0.73, outside

This means that 217.77.0.73 is your 26XX router, I would assume.

Of course, an ASA will not forward a packet to an interface on the same interface it received the packet on. So hopefully, 217.x.x.163 is not the same subnet as 217.77.0.x ... or it will not forward the packet, because the source and destination are the same interface.

No adjaceny does seem to suggest that the ASA doesn't know where to send the packet, from an IP Route perspective. Are you sure your subnets are correct everywhere?

I am assuming that you can successfully ping 217.77.0.73 from the outside interface of the ASA, and that when you do a "show arp" you see the correct mac address for it?

Addionally, in phase 2, in your success, it immediately finds a route in 10.183.0.0 255.255.0.0 outside... but in your failure, it doesn't find a route.

Also, notice that in the success, in phase 10, it has found a next-hop 217.nn.0.73 (is that actually 217.77.0.73, or a different 2nd octet?), along with a mac address, but in your failure, it doesn't find an adjacency (i.e. no interface with a broadcast domain able to ARP a next hop that leads to the destination network) ?

show run | i route

maybe also look at

show route

show ip

and see if you've typo'd an octet or a mask somewhere? Or if you're experiencing some problem with subnetting gone awry.

I find when my eyes are blurry from working on something for too long, it helps to cut and paste the whole config, and then cut/paste the lines into side-by-side text editor windows so I can compare line by line, and then I'll use tabs/white space to make the IPs and masks directly ontop of each other so I can easily see typos. Anything to increase the contrast, so to speak.

Anyways, if I completely misunderstood the network layout, my apologies 🙂

Re: PIX blocking unspecified traffic

chrisgray1 — Wed, 17 Sep 2008 08:38:55 GMT

Hi,

Firstly, thanks both, for the help so far.

Here are the answers to the questions you have asked.

From your description - VPN traffic should be passin THRU the pix to terminate on the 26xx, is this correct?

The traffic TO BE VPN'd is sent through the PIX to the 2600 which is the router that this customers VPN is configured on. Then on the return path ie. from the customers LAN to us the VPN traffic is decrypted at the 2600 and then forwarded to the PIX. The PIX has the server subnet 217.nn.n.128/26 directly connected on its vlan309-e3 interface.

Maltuna, you are more or less correct, the packet is routed as follows.

host (217.x.x.164) -> in to PIX vlan309-e3 interface (217.x.x.128) -> out of PIX outside interface (217.77.0.?) -> 2600 router(217.77.0.73) -> VPN tunnel -> (10.0.32.1) endpoint

where packet only gets as far as:

host -> ASA -> (dropped), except its a PIX 525 not ASA

The IP network between the 2600 router and the PIX is a single CAT6k switch. I feel that the routing is fine between the PIX and 26k because a traceroute to it from the PIX goes straight to the 2600 before being dropped, because as mentioned before the tunnel is currently down.

LIV-SVR-01# trace 10.0.32.1

Type escape sequence to abort.

Tracing the route to 10.0.32.1

1 217.77.0.73 10 msec 0 msec 0 msec

So it is JUST packets from the server subnet through the PIX to 10.0.32.0 that are dropped, not all packets from the PIX to 10.0.32.0

Anyways, you said that your routing on the ASA is correct:

S 10.0.32.0 255.255.255.0 [1/0] via 217.77.0.73, outside

This means that 217.77.0.73 is your 26XX router, I would assume.

That is correct. and the PIX does see the correct mac address in arp cache for 217.77.0.73

You are right 217.nn.0.73 = 217.77.0.73,

from the PIX

PIX-LIV-01# sh route | incl 10.0.32.0

S 10.0.32.0 255.255.255.0 [1/0] via 217.77.0.73, outside

The only other thing which confuses me, I noticed that nat-control is on so I believe we need a nat statement for each network that the PIX forwads packets between?

I take this to mean I need the following statement for inbound traffic, which I can see is in the PIX config.

static (vlan309-e3,outside) 217.nn.n.128 217.nn.n.128 netmask 255.255.255.192 where n is the same in both addresses.

but do I also need? This is not in the config.

static (vlan309-e3,outside) 10.0.32.0 10.0.32.0 netmask 255.255.255.0

Re: PIX blocking unspecified traffic

chrisgray1 — Wed, 17 Sep 2008 08:55:55 GMT

Could it be anything to do with this?

We have an internal network just for transferring data for server backups which uses the 10.0.0.0 address and the servers have dual NICs one with a 10.0.0.0 address and another with a global IP address.

The PIX routes packets to this network from its inside interface.

I can see that on the PIX we have the static nat statement as follows,

static (inside,outside) 10.0.0.0 10.0.0.0 netmask 255.255.0.0

To me this would seem to catch the customers 10.0.32.0 subnet but not their 10.183.x.x or 10.184.x.x subnets and as it is for the inside interface (where our backup network is) not the vlan309-e3 interface (where the customers servers are).

Would this cause a conflict for the PIX when looking where to send the packet?

Maybe I'm totally on the wrong track here, but hopefully one of you guys will know 🙂

thanks

Re: PIX blocking unspecified traffic

chrisgray1 — Wed, 17 Sep 2008 11:26:36 GMT

Hi, I've figured this out now.

we had the following static NAT which matched all 10.0.x.x from this interface to the inside interface.

static (inside,vlan309-e3) 10.0.0.0 10.0.0.0 netmask 255.255.0.0

I have replaced this with

static (inside,vlan309-e3) 10.0.0.0 10.0.0.0 netmask 255.255.240.0, becuase this easily covers our internal network range

and added

static (outside,vlan309-e3) 10.0.32.0 10.0.32.0 netmask 255.255.252.0

I'm now seeing the traffic making it through to the VPN router.

thanks for the help guys.

Re: PIX blocking unspecified traffic

andrew.prince — Wed, 17 Sep 2008 11:38:23 GMT

Chris,

So my post of "Check your NAT statements " helped then?

Re: PIX blocking unspecified traffic

chrisgray1 — Wed, 17 Sep 2008 12:48:19 GMT

Yes thanks