Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

VPN traffic not captured by IPSec access list

Hi,

we have two 2851's.  One in Australia, one in NZ, IPsec VPN between the two.

We have multiple subnets behind the tunnels. From all the sunbets in Aus we can reach all the subnets in NZ, except for one.  From NZ we can reach all the subnets in Aus.  The traceroute and pings from the subnet in question in Aus goes out the internet interface of the router instead of going into the tunnel.

The subnets in question are 10.110.220/24 (Aus), 10.110.250/24 (NZ)

The access lists at both ends cover the traffic required but for some reason when leaving Australia the traffic is not captured by:

Crypto Map "AUS-SYD" 20 ipsec-isakmp

    Description: Auckland VPN

    Peer = 203.167.249.46

    Extended IP access list auckland_VPN

        access-list auckland_VPN permit ip 10.110.220.0 0.0.0.255 10.110.254.8 0.0.0.7

        access-list auckland_VPN permit icmp 10.110.220.0 0.0.0.255 10.110.254.8 0.0.0.7

        access-list auckland_VPN permit ip 10.110.220.0 0.0.0.255 10.110.250.0 0.0.0.255

        access-list auckland_VPN permit icmp 10.110.220.0 0.0.0.255 10.110.250.0 0.0.0.255

        access-list auckland_VPN permit ip 10.110.220.0 0.0.0.255 10.110.251.0 0.0.0.63

        access-list auckland_VPN permit icmp 10.110.220.0 0.0.0.255 10.110.251.0 0.0.0.63

        access-list auckland_VPN permit ip 10.110.220.0 0.0.0.255 10.110.216.0 0.0.3.255

        access-list auckland_VPN permit icmp 10.110.220.0 0.0.0.255 10.110.216.0 0.0.3.255

        access-list auckland_VPN permit ip 10.110.254.0 0.0.0.7 10.110.251.64 0.0.0.63

        access-list auckland_VPN permit ip 10.110.220.0 0.0.0.255 10.110.251.64 0.0.0.63

        access-list auckland_VPN permit icmp 10.110.220.0 0.0.0.255 10.110.251.64 0.0.0.63

    Current peer: x.x.x.x

    Security association lifetime: 4608000 kilobytes/3600 seconds

    Responder-Only (Y/N): N

    PFS (Y/N): N

    Transform sets={

        ESP-DES-MD5:  { esp-des esp-md5-hmac  } ,

    }

I can provide network diagrams as well as configs for both ends of the VPN.

The attachments are

NZ-AU.jpg Diagram showing the layout of the network.

10.110.220 traces and pings from subnet which cannot get to NZ, this subnet is located in AU.

10.110.248 traces and pings from subnet which can get to NZ, this is what the above should look like, it is just another subnet in AU

10.110.250 traces and pings from subnet in NZ back to AU, including 10.110.220, it works???

Everyone's tags (2)
1 ACCEPTED SOLUTION

Accepted Solutions
VIP Purple

VPN traffic not captured by IPSec access list

The most important part is missing: your config.

What I see here is that your crypto ACL has unneeded lines. ICMP is included in IP, so you don't need the lines with "icmp".

In your output there is shown that you can ping the other side. I assume that this wouldn't work without the tunnel. So how  do you see that traffic for the other side is sent to the internet instead of the tunnel? Or are you just missing the hits in the "icmp"-lines?

-- 
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni


--
Don't stop after you've improved your network! Improve the world by lending money to the working poor: http://www.kiva.org/invitedby/karsteni
3 REPLIES
VIP Purple

VPN traffic not captured by IPSec access list

The most important part is missing: your config.

What I see here is that your crypto ACL has unneeded lines. ICMP is included in IP, so you don't need the lines with "icmp".

In your output there is shown that you can ping the other side. I assume that this wouldn't work without the tunnel. So how  do you see that traffic for the other side is sent to the internet instead of the tunnel? Or are you just missing the hits in the "icmp"-lines?

-- 
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni


--
Don't stop after you've improved your network! Improve the world by lending money to the working poor: http://www.kiva.org/invitedby/karsteni
New Member

VPN traffic not captured by IPSec access list

Hi, thanks for your reply.

You are absolutely correct. I have removed the ICMP lines from my config.

What my output shows is that I cannot ping the other side:

It was being routed incorrectly to the internet and not into the tunnel when going from the AU subnet to the NZ subnet.

From the NZ subnet I was able to ping the AU subnet.

I have resolved this. Nothing to do with the CISCO.

It was the fortigate infront of the CISCO.  The rules were not in the correct order and there was a PAT being applied to all the outbound traffic which was making it misroute.

New Member

VPN traffic not captured by IPSec access list

This issue was resolved in the following way. 

1. a trunking/swithport configuration item on the core Sydney switch;

2. the order of firewall rules on the Fortigate, which put a PAT (Port Address Translation) allow all rule prior to a rule allowing traffic from the Ack_DR subnet to all Random House subnets ( I ended up deleting every rule then adding them in one by one and seeing when the problem started to occur, once I isolated the rule responsible I further analised the rule and played with the order to get full connectivity);

3. the above two manifested themselves on the boarder CISCO router, so that traffic from Ack_DR appeared to be routed out the Internet interface instead of the VPN tunnel, routing from NZ to the Ack_DR subnet was fine.

I also removed all the ACL's for the AU-NZ vpn and reapplied them then tested connectivity while looking at the incrementing ACL count.  Also reset the ACL count and cleaned up the rules.

1011
Views
0
Helpful
3
Replies
CreatePlease login to create content