09-16-2008 05:40 AM - edited 03-11-2019 06:44 AM
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.
Solved! Go to Solution.
09-16-2008 10:18 AM
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>
09-16-2008 05:51 AM
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>
09-16-2008 06:14 AM
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
09-16-2008 06:17 AM
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
09-16-2008 06:25 AM
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.
09-16-2008 06:19 AM
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
09-16-2008 07:13 AM
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
09-16-2008 07:25 AM
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
09-16-2008 08:08 AM
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
09-16-2008 08:10 AM
Chris,
Sorry - was dealing with a work issue. OK - read your previous posts, any chance you can post a sanitised config relating to this?
09-16-2008 08:19 AM
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
09-16-2008 08:21 AM
Chris,
Just post the:-
1) Interesting traffic acl
2) no-nat ACL
3) Crypto entry
?
09-16-2008 08:34 AM
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
09-16-2008 10:18 AM
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>
09-16-2008 05:07 PM
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 :)
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: