NAT over IPSEC VPN

[Anonymous]

I am currently working on setting up an IPSEC VPN for Sprint Command Center.  They will not allow me to use my current LAN network because it is already in use by another one of their customers.  I have attempted to set it up having my LAN traffic NAT to my WAN interfaces and use my WAN interface as the selectors but it appears to not be working properly.  When Sprint sends traffic to me, the tunnel comes up.  When I send traffic to Sprint, the tunnel will not come up, so I am thinking I have something configured wrong.  Here is my config:

ip crypto

!

crypto ike policy 3

  initiate main

  respond main

  peer 66.X.X.X

  attribute 1

    encryption 3des

    authentication pre-share

    group 2

    lifetime 86400

!

crypto ike remote-id address 66.X.X.X preshared-key XXXXXXXXX ike-policy 3 crypto map VPN 3 no-mode-config no-xauth

!

crypto ipsec transform-set 3DES-SHA esp-3des esp-sha-hmac

  mode tunnel

!

crypto map VPN 3 ipsec-ike

  match address SPRINTVPN

  set peer 66.X.X.X

  set transform-set 3DES-SHA

  set security-association lifetime seconds 3600

  ike-policy 3

!

interface eth 0/1

  description WAN 1 Interface

  speed 100

  ip address  68.X.X.X  255.255.255.252

  ip ffe

  ip access-policy Public

  crypto map VPN

  no shutdown

!

!

interface eth 0/2

  description WAN 2 Interface

  ip address  72.X.X.X  255.255.255.128

  no ip proxy-arp

  ip ffe

  ip access-policy "Public 2"

  crypto map VPN

  no shutdown

!

ip access-list extended SPRINTVPN

  permit ip host 68.X.X.X  10.150.0.0 0.0.1.255

  permit ip host 68.X.X.X  10.152.0.0 0.0.1.255

  permit ip host 68.X.X.X  10.192.0.0 0.0.15.255

  permit ip host 72.X.X.X  10.150.0.0 0.0.1.255

  permit ip host 72.X.X.X  10.152.0.0 0.0.1.255

  permit ip host 72.X.X.X  10.192.0.0 0.0.15.255

!

ip access-list extended NATWAN1

  remark NAT to WAN1

  permit ip any  any     log

!

ip access-list extended NATWAN2

  remark NAT to WAN2

  permit ip any  any     log

!

ip policy-class PRIVATELAN

  allow list AdminAccess self

  nat source list NATWAN1 interface eth 0/1 overload policy Public

  nat source list NATWAN2 interface eth 0/2 overload policy "Public 2"

Thanks,

Brad

[jayh]

bchesler wrote:

I am currently working on setting up an IPSEC VPN for Sprint Command Center.  They will not allow me to use my current LAN network because it is already in use by another one of their customers.  I have attempted to set it up having my LAN traffic NAT to my WAN interfaces and use my WAN interface as the selectors but it appears to not be working properly.  When Sprint sends traffic to me, the tunnel comes up.  When I send traffic to Sprint, the tunnel will not come up, so I am thinking I have something configured wrong.  Here is my config:

***snip***

ip access-list extended SPRINTVPN

  permit ip host 68.X.X.X  10.150.0.0 0.0.1.255

  permit ip host 68.X.X.X  10.152.0.0 0.0.1.255

  permit ip host 68.X.X.X  10.192.0.0 0.0.15.255

  permit ip host 72.X.X.X  10.150.0.0 0.0.1.255

  permit ip host 72.X.X.X  10.152.0.0 0.0.1.255

  permit ip host 72.X.X.X  10.192.0.0 0.0.15.255

Are 10.150.0.0/23, 10.152.0.0/23 and 10.192.0.0/20 the remote subnets of the VPN tunnel at the Sprint end?  Those addresses aren't routeable over the Internet so you'll probably need static routes pointing them to the Sprint peer at 66.x.x.x .  Going from public addresses on your side via NAT to private addresses on their side is tricky, and will drive the next guy to look at it crazy unless it is well documented.  It might be easier to work with Sprint for an available RFC1918 network and renumber your LAN, then go private-to-private. 

For them to initiate to a specific host behind the NAT on your side you'll need to do some port-forwarding which might not scale well. 

[Anonymous]

jayh wrote:

Are 10.150.0.0/23, 10.152.0.0/23 and 10.192.0.0/20 the remote subnets of the VPN tunnel at the Sprint end? 

Yes those are the remote subnets for the VPN tunnel on Sprint end.  My selector ACL should be taking care of telling the router what to do with the traffic destined to those networks.

ip access-list extended SPRINTVPN

  permit ip host 68.X.X.X  10.150.0.0 0.0.1.255

  permit ip host 68.X.X.X  10.152.0.0 0.0.1.255

  permit ip host 68.X.X.X  10.192.0.0 0.0.15.255

  permit ip host 72.X.X.X  10.150.0.0 0.0.1.255

  permit ip host 72.X.X.X  10.152.0.0 0.0.1.255

  permit ip host 72.X.X.X  10.192.0.0 0.0.15.255

crypto map VPN 3 ipsec-ike

  match address SPRINTVPN

  set peer 66.X.X.X

  set transform-set 3DES-SHA

  set security-association lifetime seconds 3600

  ike-policy 3

jayh wrote:

Going from public addresses on your side via NAT to private addresses on their side is tricky, and will drive the next guy to look at it crazy unless it is well documented.  It might be easier to work with Sprint for an available RFC1918 network and renumber your LAN, then go private-to-private. 

For them to initiate to a specific host behind the NAT on your side you'll need to do some port-forwarding which might not scale well.

They will not be initiating traffic into our local network.  We will be initiating the traffic from our side only for remote management purposes on the devices we are deploying using Sprint services.

I know that the VPN itself is functional, because when Sprint initiated traffic from 10.152.X.X to either 68.X.X.X or 72.X.X.X, the tunnel comes up.  For some reason, when I initiate traffic from 68.X.X.X or 72.X.X.X, it is not bringing the tunnel up.  I have tried from a LAN device NATing to those IPs, as well as initiating a ping directly from those IPs on the router as well.  Any help as to what I may be missing would be very appreciated.

Thanks,

Brad

[Anonymous · Accepted solution]

I was able to resolve the issue.  After looking into the debug info, I did indeed have a problem with my selectors.  I messed up on my wild card bit conversion, so I was not matching the traffic I was trying to send.  After updating my selectors, everything is working as intended.

Thanks,

Brad