Same destination LAN on each end of a VPN tunnel.

[Anonymous]

I am configuring an IKE/IPSEC vpn tunnel between a 3430 router (with enhanced firmware) to a sonicwall firewall.  The sonicwall has a LAN address of 192.168.206.14 but is routing to a 192.168.100.0/24 network within their LAN.  The LAN for the 3430 is also addressed as 192.168.100.0/24.   I need to NAT the traffic in order to allow the VPN devices to route the traffic.  I do not have configuration control of the sonicwall.  How can this be done on the Adtran?

Thanks,

Dan

[mick]

I'd be interested to see what Adtran staff recommend as a solution to this question, because I am not sure that you can implement what you want in a pure VPN tunnel.  To state the obvious, changing the Netvanta LAN to a different subnet would achieve what you want with minimum effort (static addressing of machines within the Netvanta LAN though could make things more bothersome).

The problem that I see is that even if somehow routing between the two LANs was resolved, there can still be conflicts between different machines having potentially the same IP address and no rules as to which one takes precedence.  I don't know if some clever VPN + GRE + VLAN combo could achieve this ...  hopefully someone more knowledgeable than I will be along shortly to explain the art of the possible.

Hope this helps.

[Anonymous · Accepted solution]

- Your NetVanta 3430 should absolutely be able to NAT VPN traffic. You will essentially set up an arbitrary network on the NetVanta side for which the Sonicwall will see your traffic coming from.You will then set up NAT pools to NAT the VPN traffic inbound and outbound to and from the actual LAN network and the arbitrary network that was setup. You should only have to set this up on the NetVanta side. The Sonicwall will see the traffic coming from the arbitrary network. An example on how to set this up can be found in example #2 on page 8 in the NAT pool guide: Configuring NAT Pools in AOS

Please do not hesitate to let us know if you have any further questions.

Thanks,

Noor

[Anonymous]

Noor,

I'm assuming that I don't have to setup a multi-address pool if I just need one VPN tunnel to connect using this NAT policy.  I can configure this with a single address (no secondary addresses) on loopback 1 along with a one address NAT pool.  Or am I missing something?

Thanks,

Dan

[mick]

Sorry for being dense, but I'm struggling to understand how Netvanta will know which port/subnet to route packets to ...

Say there's a machine on IP 192.168.100.5 behind the Netvanta and another machine behind the Sonicwall, also on IP 192.168.100.5 within the Sonicwall LAN address space.  How will the Netvanta know where to send packets for 192.168.100.5 ... within its own LAN, or across the VPN tunnel?

[Anonymous]

Mick,

The way I understand this... the remote machine will not route to the actual address but the NATed address.  For example if 192.168.100.5 exists on both sides the NAT will hide the remote address behind NAT.  Let's say the NAT will translate the remote 192.168.100.5 to 172.16.100.5 before sending it across the tunnel.  Therefore, the Sonicwall will send remote traffic to 172.16.100.5 and not the 192.168.100.5.  So the remote subnet selector in the Sonicwall configuration will identify the 172.16.100.0 subnet and not the 192.168.100.0 subnet.

Thanks,

Dan

[Anonymous]

- Yes, you can NAT to a single IP address if you prefer. A reason to NAT to more than a single IP address would be if you would like to identify a certain device that is coming over the VPN (i.e. server). In that case, you would set up a 1:1 NAT and then NAT everything else to a single IP address.

As far as your response to goes, you are on the right track. By NATting the traffic before it goes over the VPN tunnel, we are making the Sonicwall believe that it is coming from a different network. Therefore, it does not think it is traffic destined to a local network. Let us know if you have any further questions.

Thanks,

Noor

[Anonymous]

Noor,

Can you clarify where I place my VPN selector and how it works with the NAT statement within the Private policy-class? Do I place one before the other?

Do I need a "nat destination list OUTSIDE-NAT pool VPN-POOL" statement in my Public1 policy-class?

Also, on as side note... is the "set interface null 0" command necessary when I have already specified the next hop in the route map LOCAL?  Isn't it enough to specify the next hop?

Any other comments you can add after reviewing my config would be welcomed!

Here is my config (only relevant portions are shown):

!

!

! ADTRAN, Inc. OS version 17.08.03.00.E

! Boot ROM version 17.06.01.00

! Platform: NetVanta 3430, part number 1202820G1

!

ip subnet-zero

ip classless

ip routing

!

ip load-sharing per-destination

ip local policy route-map LOCAL (for probes)

!

no auto-config

!

ip firewall

ip firewall fast-nat-failover

!

ip crypto

ip crypto fast-failover

!

< Many other crypto map and ike policies removed >

!

crypto ike policy 172

  initiate main

  respond main

  local-id fqdn NearEnd

  nat-traversal v2 force

  peer 88.xx.88.xx

  attribute 1

    encryption 3des

    hash md5

    authentication pre-share

    group 2

    lifetime 7200

!

crypto ike remote-id fqdn FarEnd preshared-key supersecret ike-policy 172 crypto map VPN 201 no-mode-config no-xauth nat-t v2 force

!

crypto ipsec transform-set esp-3des-esp-md5-hmac esp-3des esp-md5-hmac

  mode tunnel

crypto ipsec transform-set esp-aes-256-cbc-esp-sha-hmac esp-aes-256-cbc esp-sha-hmac

  mode tunnel

!

crypto map VPN 201 ipsec-ike

  description FarEnd

  match address VPN-201-vpn-selectors1

  set peer xx.88.xx.88

  set transform-set esp-3des-esp-md5-hmac

  set security-association lifetime seconds 7200

  ike-policy 172

!

!

no ethernet cfm

!

interface loop 1

  ip address  172.16.100.245  255.255.255.0

  ip address range  172.16.100.1  172.16.100.244  255.255.255.0  secondary

  ip address range  172.16.100.246  172.16.100.254  255.255.255.0  secondary

  no shutdown

!

interface eth 0/1

  description LAN connection

  ip address  192.168.100.245  255.255.255.0

  access-policy Private

  no rtp quality-monitoring

  no shutdown

!

!

interface eth 0/2

  description PrimaryWAN

  ip address  xx.xx.xx.114  255.255.255.248

  access-policy Public1

  crypto map VPN

  no rtp quality-monitoring

  no shutdown

!

!

interface t1 1/1

  tdm-group 1 timeslots 1-24 speed 64

  no shutdown

!

interface ppp 1

  description SecondaryWAN

  ip address  xx.xx.xx.102  255.255.255.252

  access-policy Public2

  crypto map VPN

  peer default ip address 63.234.116.101

  no shutdown

  cross-connect 1 t1 1/1 1 ppp 1

!

route-map LOCAL permit 10

  match ip address WAN1

  set ip next-hop xx.xx.xx.113

  set interface null 0

route-map LOCAL permit 20

  match ip address WAN2

  set ip next-hop xx.xx.xx.101

  set interface null 0

!

ip access-list extended INSIDE-NAT

  permit ip 192.168.100.0 0.0.0.255  192.168.206.0 0.0.0.255   

!

ip access-list extended NAT1

  remark NAT1 list

  permit ip any  any   

!

ip access-list extended NAT2

  remark NAT2 list

  permit ip any  any   

!

ip access-list extended OUTSIDE-NAT

  permit ip 192.168.206.0 0.0.0.255  172.16.100.0 0.0.0.255   

!

ip access-list extended Remote-access

  remark Admin Access

  permit tcp any  any eq www   log

  permit tcp any  any eq telnet   log

  permit tcp any  any eq https   log

  permit tcp any  any eq ssh   log

  permit icmp any  any  echo   log

!

ip access-list extended self

  remark Traffic to NetVanta

  permit ip any  any     log

!

!

ip access-list extended VPN-201-vpn-selectors1

  permit ip 172.16.100.0 0.0.0.255  192.168.206.0 0.0.0.255   

!

!

ip nat pool VPN-POOL static

  local 192.168.100.1 192.168.100.254 global 172.16.100.1 172.16.100.254

!

ip policy-class Private

  allow list VPN-201-vpn-selectors1 stateless

  allow list self self

  nat source list INSIDE-NAT pool VPN-POOL policy Public1

  nat source list NAT1 interface eth 0/2 overload policy Public1

  nat source list NAT2 interface ppp 1 overload policy Public2

!

ip policy-class Public1

  allow reverse list VPN-201-vpn-selectors1 stateless

  allow list Remote-access self

  nat destination list OUTSIDE-NAT pool VPN-POOL

!

ip policy-class Public2

  allow list Remote-access self

!

ip route 0.0.0.0 0.0.0.0 xx.xx.xx.101

ip route 0.0.0.0 0.0.0.0 xx.xx.xx.113 track XXX

!

...end

[Anonymous]

- Since you are NATting your VPN traffic, the VPN selectors do not need to be 'allowed' through the firewall. As long as they are referenced as the VPN selectors in the crypto map, they will be encrypted once the NAT has taken place. Therefore, you will only need to ensure that the NAT rule is listed in the public and private policy-class.

The 'set interface null 0' command is not necessarily needed. The command would only take place if the next-hop IP specified in the route-map is unavailable.

The rest of your configuration looks correct. The only thing I would suggest is removing the "allow list VPN-201-vpn-selectors1 stateless" rule from the Private policy-class and "allow reverse list VPN-201-vpn-selectors1 stateless" from the Public policy-class as these rules are not doing anything.

Please do not hesitate to let us know if you have any more questions.

Thanks,

Noor

[Anonymous]

One further note, the VPN selectors must be configured to select the traffic as viewed from the peer.  I tried configuring my VPN selector ACL using the inside address of my LAN and it failed. 

After making the changes and playing around with the respond mode, the DH group, and the NAT-T the tunnel finally came up and the peer was able to NAT correctly.

Thanks noor !

[mick]

danb wrote:  One further note, the VPN selectors must be configured to select the traffic as viewed from the peer.  I tried configuring my VPN selector ACL using the inside address of my LAN and it failed.

Yes, so it should!  I think I got it now! 

The mechanism suggested by noor is different to the vanilla VPN that I had in mind, where policy-class stateless connections manage the traffic through the Netvanta.  In your implementation, using your LAN address fails because both Netvanta and Sonicwall have the same LANs.  The NAT mechanism will change the source packet headers from say 192.168.100.5 to the NAT'ed address facing the peer.  Hence, no clash between the two LANs.

Thank you both for helping me understand this.