cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1986
Views
0
Helpful
20
Replies

PIX blocking unspecified traffic

chrisgray1
Level 1
Level 1

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.

1 Accepted Solution

Accepted Solutions

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>

View solution in original post

20 Replies 20

andrew.prince
Level 10
Level 10

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>

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

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

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.

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

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

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

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

Chris,

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

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

Chris,

Just post the:-

1) Interesting traffic acl

2) no-nat ACL

3) Crypto entry

?

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

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>

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 :)

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: