I'm currently having major issues getting an IPSEC VPN client to work properly on an IOS router. The VPN client will connect and I can ping any interface that is on the router itself. However, I cannot communicate with anything beyond the router. I have completely removed the VPN config and rebuilt it several times. I've checked ACLS and routing. I'm not sure what the issue is here.
Per CDP the LAN layout is:
vpn client ----- Internet ---- 2851 VPN router --- csw02 ---- csw01 --- Server we need to reach (172.18.0.38)
VPN client Pool: 10.1.8.0 /24
2851 VPN Router 172.18.3.1 vlan 13
cssw02 172.18.3.230 vlan 13
cssw02 172.18.3.254 vlan 13
The trunks between the switches are DOT1Q with Vlan 13 native (172.18.3.0 /24 subnet).
Once the VPN client connects, I receive an IP of 10.1.8.10, then I can ping the router at 172.18.3.1 or any other subinterface on the router. I cannot ping beyond the router. Pings to the server on cssw01 at 172.18.0.38 fail. Pings to any SVI on the switches fail. A look in the statistics of the Cisco VPN client shows the correct secured route. I am attaching sanitized configs. I appreciate any help with this. Thank you!
These routes are useless because you already have a direct connected interface having an ip in these subnets:
ip route 172.18.0.0 255.255.255.0 172.18.3.254 ip route 172.18.3.0 255.255.255.0 172.18.3.254
Can you try to ping 172.18.0.254?
I agree. I removed the routes. From the VPN Client connected computer I cannot ping 172.18.0.254. I can ping 172.18.0.1, because it is on the router.
The vpn client appears to be properly injecting the routes from the split-tunnel ACL. I turned off ip routing on the csw02 switch. It's running as a layer 2 switch now. ip routing is enabled on csw01 with a route sending 10.1.8.0/24 traffic back to the router at 172.18.3.1.
Screenshot of vpn client routes:
From the output of the debug ip icmp it looks like the packet it making it to the switch. Here is the requested info:
2851-CME-rtr#show ip nat trans
Pro Inside global Inside local Outside local Outside global
udp 12.x.x.66:4500 12.x.x.66:4500 173.x.x.233:58343 173.x.x.233:58343
csw01#debug ip icmp
ICMP packet debugging is on
ICMP packet debugging is on
000050: 1d01h: ICMP: echo reply sent, src 172.18.0.254, dst 10.1.8.14
000051: 1d01h: ICMP: echo reply sent, src 172.18.0.254, dst 10.1.8.14
000052: 1d01h: ICMP: echo reply sent, src 172.18.0.254, dst 10.1.8.14
000053: 1d01h: ICMP: echo reply sent, src 172.18.0.254, dst 10.1.8.14
000054: 1d01h: ICMP: echo reply sent, src 172.18.0.254, dst 10.1.8.14
000055: 1d01h: ICMP: echo reply sent, src 172.18.0.254, dst 10.1.8.14
2851-CME-rtr#show ip route
Gateway of last resort is 12.x.x.65 to network 0.0.0.0
S* 0.0.0.0/0 [1/0] via 12.x.x.65
10.0.0.0/32 is subnetted, 2 subnets
S 10.1.8.14 [1/0] via 173.x.x.233, GigabitEthernet0/1
C 10.1.8.150 is directly connected, Loopback10
184.108.40.206/8 is variably subnetted, 2 subnets, 2 masks
C 12.x.x.64/28 is directly connected, GigabitEthernet0/1
L 12.x.x.66/32 is directly connected, GigabitEthernet0/1
172.18.0.0/16 is variably subnetted, 16 subnets, 2 masks
C 172.18.0.0/24 is directly connected, GigabitEthernet0/0.10
L 172.18.0.1/32 is directly connected, GigabitEthernet0/0.10
C 172.18.1.0/24 is directly connected, GigabitEthernet0/0.2
L 172.18.1.253/32 is directly connected, GigabitEthernet0/0.2
S 172.18.2.0/24 [1/0] via 172.18.3.254
C 172.18.3.0/24 is directly connected, GigabitEthernet0/0.1
L 172.18.3.1/32 is directly connected, GigabitEthernet0/0.1
S 172.18.4.0/24 [1/0] via 172.18.3.254
For your acl split-tunnel, instead of extended acl, change it to standard acl by configuring only subnets without any keyword at the end and test again please.
I think I tried that before, but the issue was that the client configuration group will not let me specify a standard list.
2851-CME-rtr(config)#crypto isakmp client configuration group IPSECVPN
<100-199> access-list number for split-tunneling
WORD Access-list name
<1-99> IP standard access list
<100-199> IP extended access list
I changed the ACL, but it still won't ping.
access-list 110 permit ip 172.18.0.0 0.0.0.255 10.1.8.0 0.0.0.255
access-list 110 permit ip 172.18.1.0 0.0.0.255 10.1.8.0 0.0.0.255
access-list 110 permit ip 172.18.3.0 0.0.0.255 10.1.8.0 0.0.0.255
000141: 1d02h: ICMP: echo reply sent, src 172.18.0.254, dst 10.1.8.12
000142: 1d02h: ICMP: echo reply sent, src 172.18.0.254, dst 10.1.8.12
csw01#show ip route
Gateway of last resort is 172.18.3.1 to network 0.0.0.0
172.18.0.0/24 is subnetted, 11 subnets
C 172.18.30.0 is directly connected, Vlan30
C 172.18.16.0 is directly connected, Vlan26
C 172.18.15.0 is directly connected, Vlan25
C 172.18.10.0 is directly connected, Vlan20
C 172.18.6.0 is directly connected, Vlan16
C 172.18.4.0 is directly connected, Vlan14
C 172.18.5.0 is directly connected, Vlan15
C 172.18.2.0 is directly connected, Vlan12
C 172.18.3.0 is directly connected, Vlan13
C 172.18.0.0 is directly connected, Vlan10
C 172.18.1.0 is directly connected, Vlan11
10.0.0.0/24 is subnetted, 1 subnets
S 10.1.8.0 [1/0] via 172.18.3.1
S* 0.0.0.0/0 [1/0] via 172.18.3.1
I'm remote to the router. I'm not sure how to do a wireshark trace without disconnecting myself.
I created an ACL on the router and ran the debug against it. When I ping from the vpn to the switch there is no output on the router's terminal.
access-list 175 permit ip 172.18.0.0 0.0.0.255 10.1.8.0 0.0.0.255 log-input
access-list 175 permit ip 10.1.8.0 0.0.0.255 172.18.0.0 0.0.0.255 log-input
debug ip packet 175
From VPN client computer:
I created a capture for interface G0/0.1 and G0/0.10. On both captures I pinged 172.18.3.254 and 172.18.0.254 from the VPN client computer.
In the G0/0.1 capture it does show the ICMP request and echo.
In the G0/0.10 capture it only shows the request for the ping to 172.18.0.254. It looks like those requests are going across G0/0.10, but the reply is trying to return on G0/0.10. If you look at the capture for G0/0.1 you can see the reply but not the requests.