I really need some assistance with this.  Anyone???   Update:  I updated the IOS on the router and the switches - still nothing. I moved the gateway of 172.18.3.254 from the switch to the router. - still nothing. I tried a different router - vpn would connect, still could not reach 172.18.0.38.               ... View more

The strange thing is that even though .3.254 looks good in wireshark.  The vpn client does not receive the ICMP replies.  Even when testing from different networks and hot spots. I upgraded the IOS on the 2851 router yesterday and it made no difference.  I also tried IPSEC over TCP port 10000 and it didn't work.     ... View more

Bump.  Anyone? ... View more

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.     ... View more

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.     Router: 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: ping 172.18.0.254   ... View more

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   csw01# 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.         ... View more

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 2851-CME-rtr(config-isakmp-group)#acl ? <100-199> access-list number for split-tunneling WORD Access-list name 2851-CME-rtr(config)#access-list ? <1-99> IP standard access list <100-199> IP extended access list ... View more

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 12.0.0.0/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 ... View more

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 csw01# csw01# csw01#show debug Generic IP: ICMP packet debugging is on csw01#term mon csw01# 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 ... View more

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: ... View more

I ended up getting this to work.  I wanted to follow up in case anyone else needed this.  It's a little embarrassing why it wouldn't ping.  The R3 interface ended up being administratively shutdown.  I guess I had disabled it while testing and forgot to re-enable it before moving back to R2. Policy-based routing was working properly to send the 10.0.12.0/24 traffic out R3.  The issue I had was that the traffic would drop once it hit the ISP2 router.  The issue was that I had not applied NAT to the R3 router.  Once I applied NAT on both R2 and R3 everything worked perfectly. ... View more

I think I see the issue, now to troubleshoot: SW2#ping 172.16.20.2 source vlan125 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.20.2, timeout is 2 seconds: Packet sent with a source address of 10.0.12.1 ..... Success rate is 0 percent (0/5) ----------------------------------------------------------------------------------------------------------- SW2#ping 172.16.20.1 source vlan125 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.20.1, timeout is 2 seconds: Packet sent with a source address of 10.0.12.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/9 ms That's strange since I can failover R2 and everything will go out R3 when pinging from the workstation off of switch 1. EIGRP is the following now: ASA router eigrp 175 network 10.10.10.0 255.255.255.252 network 172.16.20.0 255.255.255.248 no auto-summary ========================================================================== Switch 2 router eigrp 175 network 10.0.2.0 0.0.0.255 network 10.0.12.0 0.0.0.255 network 172.16.20.0 0.0.0.7 no auto-summary ========================================================================== R2 router eigrp 175 redistribute static metric 100000 100 255 1 1500 network 10.10.10.0 0.0.0.3 no auto-summary router eigrp 25 redistribute eigrp 175 network 1.1.1.0 0.0.0.7 network 10.10.10.0 0.0.0.3 no auto-summary ip route 0.0.0.0 0.0.0.0 1.1.1.2 ========================================================================== R3 router eigrp 175 redistribute static metric 100000 120 255 1 1500 network 172.16.20.0 0.0.0.7 no auto-summary router eigrp 25 redistribute eigrp 175 network 2.2.2.0 0.0.0.3 network 172.16.20.0 0.0.0.7 no auto-summary ip route 0.0.0.0 0.0.0.0 2.2.2.1 ... View more

Yes policy-based routing seems to be part of the solution.  I've made progress.  EIGRP was a disaster.  I reworked all of the EIGRP configs and have the routing working correctly now.  All traffic is going out R2.  If I shutdown an interface on R2 all traffic will reroute out R3. The layer 3 switch is a 3850 with IP services.  It supports PBR.  I've configured PBR on it and told it to set the next hop for subnet 10.0.12.0/24 to 172.16.20.2.  Although the traffic matches my access-list and route-map, it does not send the traffic out the correct way.  The traffic will only follow the gateway of last resort set by EIGRP. interface Vlan125 ip address 10.0.12.1 255.255.255.0 ip route-cache policy ip policy route-map PBR4VLAN125 access-list 110 permit ip 10.0.12.0 0.0.0.255 any route-map PBR4VLAN125 permit 10 match ip address 110 set ip next-hop 172.16.20.2 SW2#show access-list 110 Extended IP access list 110 10 permit ip 10.0.12.0 0.0.0.255 any (7 matches) SW2#show route-map PBR4VLAN125 route-map PBR4VLAN125, permit, sequence 10 Match clauses: ip address (access-lists): 110 Set clauses: ip next-hop 172.16.20.2 Policy routing matches: 7 packets, 879 bytes ... View more