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
- 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
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.
- 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
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
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?
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
- 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
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
- 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
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 !
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.