VPN with Mobile ShewSoft Client

[hogle]

It appears I'm able to establish a valid VPN tunnel. ShewSoft reports the tunnel enabled. Stays up until the lifetime expires. On the Adtran 3458 side I see the Security Associations established. I can watch the lifetime countdown. I have 192.168.125.0/255.255.255.0 configured as the remote network policy on the PC client side. Yet, I am unable to get any traffic to traverse the tunnel, or so it appears.

I followed the ShrewSoft directions for configuring the client, making only minor adjustments for the crypto config on the Adtran side. I've looked at VPN discussions trying to be enlightened and tried too many things to mention.

Attached is my config. Maybe I'm just overlooking something. Please help.

[hogle]

What I am trying to do is simply allow PC clients access to the default VLAN 1, 192.168.125.0.

Description of the Configuration: This is a production config. The Probes and Track are currently only for reporting. Plans are to later use them for failover. There are three WAN connections. Vlan124, 192.168.124.0, is a separate VOIP subnet. VOIP traffic is also located on VLAN 1 192.168.125.0.  Subnet 192.168.127.0 is a static IP address only DMZ.  The ACLs, Policies, and PBRs are used to map various servers and servers to the desired port addresses.

References in the config  to Cisco VPN are for an external VPN appliance. It works. It provides its own DHCP pool and presents VPN users to VLAN1 as regular 192.168.125.xxx nodes via its Private interface connected to a switch. The router is providing routing to the VPN Public interface in the DMZ. The Cisco VPN works with our Apple IOS users as long as it is configured to tunnel everything.

Everything seems to work, except the Adtran VPN.

As far as the Adtran VPN issue is concerned, this should be straight forward. We simply want the VPN clients to have access to the 192.168.125.0 subnet, split DNS. The tunnel seems to only work with the "crypto ike client configuration pool VpnUsers" in place. It seems to also require the pool to be a different subnet, other than "125". I tried it without the pool and the same "125" subnet. None of those attempts established a tunnel. With this configuration, I seem to have a tunnel, but no traffic. I tried setting up a VLAN 126 with ACL and Policies. But, that also caused the tunnel to fail IKE negotiation. So, now I wonder if something in my PBR is preventing traffic to traverse the tunnel? But, I would expect to see some packets during debug. I don't. Another thought is NAT traversal. Is that my issue? At this point, I don't know. Uncertain how best to troubleshoot.

Any help is appreciated.

[mick]

Hi hogle,

Unless you omitted pasting all the configuration your VPN section appears to be incomplete.  For example:

crypto ike remote-id user-fqdn <user@fqdn> preshared-key <SharedSecret> ??????

The above should additionally include an ike-policy:

crypto ike remote-id user-fqdn <user@fqdn> preshared-key <SharedSecret> ike-policy 100

It should also include a crypto map:

crypto ike remote-id user-fqdn <user@fqdn> preshared-key <SharedSecret> ike-policy 100  crypto map VPN 10

Note: RADIUS must use PAP authentication for the Netvanta to work when using Xauth with VPN connections, so check that you are not trying to use some other type of authentication.

RADIUS Authentication for VPN Clients in AOS - CAG

Finally, add nat-t v2 allow at the end if you need NAT Traversal.

The above additions should get an IPSec tunnel going.  Ping from a client to see that you can get through and run a debug session on the router to see that all is well.

Hope this helps.

--

Regards, Mick

[hogle]

Thanks Mick!

Good catch, I was missing the "ike-policy 100  crypto map VPN 10" at the end of my "crypto ike remote-id" line. I made the changes as suggested. No traffic, yet. I also tried adding the nat-t v2 allow at the end. I also tried adding nat traversal v2 allow to the policy. After various attempts including disable and force, I discovered that apparently allow is the default and does not display when showing the configuration. The nat-t v1/v2 only display when set to disable or force.

I also tried configuring VPN through the https GUI. Same results, no traffic. According to the ShrewClient the tunnel gets established. But, I was getting that message previously. It's possible that I accidentally dropped the "ike-policy 100  crypto map VPN 10" on the "crypto ike remote-id" line somewhere along the line in my various attempts.

I verified that RADIUS is working and using PAP.

At this point, I believe I have VPN configured as suggested. I've been working on this on/off for weeks now. I thought I had both an IKE SA and IPSEC SA established a couple weeks ago. Currently, I only see an IKE SA established. Although, I'm not quite sure what I'm supposed to see in a good VPN. This is still my first Adtran VPN configuration.

I can successfully establish a VPN with our Cisco VPN appliance using ShrewSoft. I've tried the same and various other client settings with Adtran. Still no traffic across the VPN.

Attached is a debug session. Any help is appreciated.

Thanks, Hogle

[hogle]

I've made some progress. After completing my "crypto ike remote-id" as pointed out by Mick, above... I've discovered that the only authorization combination that seems to works is: user-fqdn (email address) for the remote mobile client and fqdn (domain name) for the gateway (router). I don't understand why only this combination. In any case, I now see two IPSEC SA in effect:

Router#show crypto ipsec sa
Using 2 SAs out of 2000
Peak concurrent SAs: 4
IPSec Security Associations:

Peer IP Address: 96.36.85.134
  Mode-config Address: 192.168.126.128
  Remote ID: vpn@acme.com
  Crypto Map: VPN 10
  Direction: Inbound
  Encapsulation: ESP
  SPI: 0xB3E37FE7 (3018031079)
  RX Bytes: 0
  Selectors: Src:192.168.126.128/255.255.255.255  Port:ANY  Proto:ALL IP
             Dst:192.168.125.0/255.255.255.0  Port:ANY  Proto:ALL IP
  Hard Lifetime: 3260
  Soft Lifetime: 0
  Out-of-Sequence Errors: 0

Peer IP Address: 89.50.194.29
  Mode-config Address: 192.168.126.128
  Remote ID: vpn@acme.com
  Crypto Map: VPN 10
  Direction: Outbound
  Encapsulation: ESP
  SPI: 0x4A172F1A (1243033370)
  TX Bytes: 0
  Selectors: Src:192.168.125.0/255.255.255.0  Port:ANY  Proto:ALL IP
             Dst:192.168.126.128/255.255.255.255  Port:ANY  Proto:ALL IP
  Hard Lifetime: 3260
  Soft Lifetime: 3180

I think this means I have a valid tunnel. Yet, I'm still unable to pass traffic. I'm not sure if the "Soft Lifetime: 0" on the inbound route is a problem or what it means. I think the selectors look reasonable.

I had the VPN getting this far weeks ago before I broke it. I've tried putting a debug ACL on the 192.168.126.0 subnet while trying to send traffic, pings and DNS requests, from a client. Don't see any anything. The client doesn't get any responses. I have the client policy set to subnet 192.168.125.0/24.

I have a somewhat complex PBR, policy based routing, rules. I think I have it right. Maybe I've missed something?

I'm not sure where to go from here.

[mick]

Hi hogle,

You've made good progress indeed. 

From what I recall the router would need to use an IP address as an identifier if the tunnel is in Main Mode and you use PSK.  The mobile client identifier can be anything.  Note:  The Aggressive Mode with a PSK is not really secure and should be avoided for a production setup.

In the debug content you posted, Phase 2 of the negotiation is not completed and SAs are not being established between the peers.  However, from what you show in your last message above you have IPSec SAs established and therefore you have a tunnel going between the two peers.  Therefore, you should now be able to connect from your mobile peer to hosts inside the router's LAN (92.168.125.0/24).

Have you tried pinging a PC which is configured to respond to pings received from subnet 192.168.126.0/24 ?

Are there any services running on the LAN PC which the mobile peer can attempt to connect to by pointing it to 92.168.125.XXX?

--

Regards,

Mick

[hogle]

Thanks Mick,

The previously attached debug was during a period that Phase 2 was not completing. I started getting IPSEC SA's established after I got everything matching on both ends; router and client settings. Actually, I'm back to where I was in my original post; tunnel established and no traffic passing.

You make a good point about aggressive mode. Until now, most of the mobile client examples I've read used aggressive. For production, I agree that main mode would be better.

I am unable to ping or connect to any services from the 192.168.126.128/32 client to anything on the 192.168.125.0/24 subnet. There are numerous machines and several servers on the 125 subnet.

The client is a standard Win 8.1 laptop with ICMP responses enabled. ShrewSoft seems to use a virtual adapter for the tunnel. I tried pinging the client from the router. Nothing.

Router#show crypto ipsec sa
Using 2 SAs out of 2000
Peak concurrent SAs: 4
IPSec Security Associations:

Peer IP Address: 96.36.85.134
  Mode-config Address: 192.168.126.128
  Remote ID: vpn@acme.com
  Crypto Map: VPN 10
  Direction: Inbound
  Encapsulation: ESP
  SPI: 0xD8AA23A5 (3635028901)
  RX Bytes: 0
  Selectors: Src:192.168.126.128/255.255.255.255  Port:ANY  Proto:ALL IP
             Dst:192.168.125.0/255.255.255.0  Port:ANY  Proto:ALL IP
  Hard Lifetime: 3530
  Soft Lifetime: 0
  Out-of-Sequence Errors: 0

Peer IP Address: 107.184.99.46
  Mode-config Address: 192.168.126.128
  Remote ID: vpn@acme.com
  Crypto Map: VPN 10
  Direction: Outbound
  Encapsulation: ESP
  SPI: 0xD3C14A4E (3552660046)
  TX Bytes: 0
  Selectors: Src:192.168.125.0/255.255.255.0  Port:ANY  Proto:ALL IP
             Dst:192.168.126.128/255.255.255.255  Port:ANY  Proto:ALL IP
  Hard Lifetime: 3530
  Soft Lifetime: 3480

Router#ping 192.168.126.128
Type CTRL+C to abort.
Legend: '!' = Success, '?' = Unknown host, '$' = Invalid host address
        '*' = Request timed out, '-' = Destination host unreachable
        'x' = TTL expired in transit, 'e' = Unknown error

Sending 5, 100-byte ICMP Echos to 192.168.126.128, timeout is 2 seconds:
*****
Success rate is 0 percent (0/5)
Router#

If I truly have a tunnel established, I'm wondering if this is a firewall or routing issue?

Thanks,

hogle

[mick]

Yes, for a production system you should be using Main Mode, a stronger transform set (e.g. esp-aes-256-cbc-esp-sha-hmac, or stronger combo when Adtran upgrade their ciphers to stronger DH and SHA2) and also use SSL certificates instead of PSK.

I assume that you have the 'crypto map VPN' applied on the correct interface (interface eth 0/1) and your vpn.acme.com resolves to eth 0/1's primary address?

Can you please re-confirm what you can and what you cannot ping?  Can you ping 192.168.125.2?  Can you ping the DNS repeater 192.168.125.8?

Have you run a debug session to see what comes through the Netvanta and checked the LAN client to see if ICMP packets arrive at all?

--

Regards,

Mick

[hogle · Accepted solution]

Finally opened a case with Adtran support. We were able to solve his.

VPN traffic is not compatible with PBR, policy based routing. Referring to the config posted, there are a number of route-map entries that set the next hop basted upon an address match in the config posted above. Apparently, these PBR entries intercept further processing of the VPN traffic back to the VPN client, causing the VPN traffic to not traverse the tunnel. Notice in this example, a lot of the route-maps are redundant with the default route. Simply removing the route-maps that are redundant with the default route allows VPN to work properly. It is also noted, that having redundant route-maps is less efficient than allowing traffic to take the default route. PBR causes additional processing that is not necessary in this path(s).

In this example network, outside the scope of the router, removing PBR route-maps that were the same as the default route had some other adverse affects. This is also correctable. The PBR route-map next hop instructions were correcting some other deficiencies of a few multi-homed server interfaces. The ultimate solution was to correct the interface configurations of those machines, allowing the default route or weighted route(s) to do there job without the need for PBR route-map statements.

Problem solved. Thank-you to everybody that contributed, especially the great support at Adtran.