VPN Tunnel Remote WAN IP Change Prevents Access Behind the LAN
We have 5 site's. 4 are using a Cisco RV320 router and the 5th is using a Secure Computing router.
They each have a hardware VPN Tunnel to Rogers Hosted Servers. This provides the end user's access to an application on their network that is crucial to running their business.
Rogers is changing the WAN IP. Therefore, we have to change each site's Router's VPN Remote WAN IP so the VPN continues to function.
Once the IP's are changed, the VPN comes back up and connection between both end's is established. However, we can no longer ping behind the LAN on Roger's end over the VPN tunnel therefore can no longer access the required application via the VPN Tunnel.
Roger's believes this is a setup issue on our end, however, nothing has changed except the Remote WAN IP on the VPN Tunnel to their side. This has also been tested on 4 of the 5 sites. 3 of them Cisco RV320's and 1 Secure Computing Router. No changes have taken place in the LAN or WAN at these site's either.
The VPN policy being used is as follows:
Key mode:
IKE with Preshared key
Local Group Setup:
Defines the local site WAN IP and local Subnet
Remote Group Setup:
Defines the remote site WAN IP and the remote LAN Subnet
IPSec Setup:
Phase 1 DH: Group 2 - 1024 bit
PHase 1 Encrypt: 3DES
Phase 1 Auth: SHA1
Phase 1 Lifetime: 86400
Perfect forward secrecy: NA
Phase 2: Encrypt: 3DES
Phase 2: SHA1
Phase 2 Ligrtime: 3600
Additional Settings:
Keep-Alive Enabled
Dead Peer Detection Interval: 10 seconds
Any idea's on what would cause this?
Thanks!
They each have a hardware VPN Tunnel to Rogers Hosted Servers. This provides the end user's access to an application on their network that is crucial to running their business.
Rogers is changing the WAN IP. Therefore, we have to change each site's Router's VPN Remote WAN IP so the VPN continues to function.
Once the IP's are changed, the VPN comes back up and connection between both end's is established. However, we can no longer ping behind the LAN on Roger's end over the VPN tunnel therefore can no longer access the required application via the VPN Tunnel.
Roger's believes this is a setup issue on our end, however, nothing has changed except the Remote WAN IP on the VPN Tunnel to their side. This has also been tested on 4 of the 5 sites. 3 of them Cisco RV320's and 1 Secure Computing Router. No changes have taken place in the LAN or WAN at these site's either.
The VPN policy being used is as follows:
Key mode:
IKE with Preshared key
Local Group Setup:
Defines the local site WAN IP and local Subnet
Remote Group Setup:
Defines the remote site WAN IP and the remote LAN Subnet
IPSec Setup:
Phase 1 DH: Group 2 - 1024 bit
PHase 1 Encrypt: 3DES
Phase 1 Auth: SHA1
Phase 1 Lifetime: 86400
Perfect forward secrecy: NA
Phase 2: Encrypt: 3DES
Phase 2: SHA1
Phase 2 Ligrtime: 3600
Additional Settings:
Keep-Alive Enabled
Dead Peer Detection Interval: 10 seconds
Any idea's on what would cause this?
Thanks!
ASKER
Hi John. Thanks for your prompt response.
The Subnet will not be an issue here since no changes on any local or remote subnet have been changed. Also note, that this works perfectly fine on the current VPN Remote WAN IP we're using. This only happens when we change it to their new one.
Additionally, I tried enabling NAT Traversal as well but this didn't do the trick.
The Subnet will not be an issue here since no changes on any local or remote subnet have been changed. Also note, that this works perfectly fine on the current VPN Remote WAN IP we're using. This only happens when we change it to their new one.
Additionally, I tried enabling NAT Traversal as well but this didn't do the trick.
Perhaps delete the VPN Profile and set it up again. That works for me sometimes. You had it working so setting it up is fairly easy. That might correct some error we cannot see.
ASKER
Hi John. We also created new VPN tunnels and performed all the necessary reboot's but the problem persisted.
Sorry I've left these fine details out of the picture.
Sorry I've left these fine details out of the picture.
I had this issue with a Juniper router at a client and we rebuilt the tunnel at the client to fix it.
Also check the firewalls at both end to be sure access is allowed through.
Here is a sanitized setup:
Description
Tunnel Number 5
Interface on Router WAN 1
Enabled
Local Gateway Type: IP Only
(External) IP address
Local Security Group type: Subnet
192.168.000.0
255.255.255.0
Remote Gateway Type: Dyn IP + Email (or what you need)
Remote IP address or email address (these two are likely IP for you)
Remote Security Group type: Subnet
192.168.222.0
255.255.255.0
Keying Mode: IKE Pre-share
Phase 1
Group 2
3DES
SHA1
28800 Sec.
PFS OFF
Phase 2
Group 2
3DES
SHA1
3600 Sec.
Pre-shared key
Advanced
Main Mode (for site to site)
Compress OFF
Keep Alive ON Default
AH Hash (MD5) I have OFF
NetBIOS OFF
Nat Traversal ON or OFF whichever works
Also check the firewalls at both end to be sure access is allowed through.
Here is a sanitized setup:
Description
Tunnel Number 5
Interface on Router WAN 1
Enabled
Local Gateway Type: IP Only
(External) IP address
Local Security Group type: Subnet
192.168.000.0
255.255.255.0
Remote Gateway Type: Dyn IP + Email (or what you need)
Remote IP address or email address (these two are likely IP for you)
Remote Security Group type: Subnet
192.168.222.0
255.255.255.0
Keying Mode: IKE Pre-share
Phase 1
Group 2
3DES
SHA1
28800 Sec.
PFS OFF
Phase 2
Group 2
3DES
SHA1
3600 Sec.
Pre-shared key
Advanced
Main Mode (for site to site)
Compress OFF
Keep Alive ON Default
AH Hash (MD5) I have OFF
NetBIOS OFF
Nat Traversal ON or OFF whichever works
With IKE Phase 1 there are ID's involved.
Those are Either the remote gateways IP address (MUST match)... so it may be the remote announcing the wrong ID...? (unless 0.0.0.0 was configured meaning use my public address).
so the ID's can be fake domain names (name.x) or fake mail addresses (whatever@name.x). Id's must match accross the connection.
Those are Either the remote gateways IP address (MUST match)... so it may be the remote announcing the wrong ID...? (unless 0.0.0.0 was configured meaning use my public address).
so the ID's can be fake domain names (name.x) or fake mail addresses (whatever@name.x). Id's must match accross the connection.
ASKER
HI Noci,
If they didn't match they wouldn't establish a connection, correct? The VPN Tunnel is established successfully on both ends. It is just our end that can no longer communicate behind their LAN.
John,
I advised Roger's to double check their firewall settings but they advise that it's fairy open and so is ours.
I almost suspect that maybe the WAN interface the new IP is on is not routed properly to their LAN interface and this is what is preventing us from browsing behind. Unfortunately, I have no access to that system so am unsure how it's configured.
If they didn't match they wouldn't establish a connection, correct? The VPN Tunnel is established successfully on both ends. It is just our end that can no longer communicate behind their LAN.
John,
I advised Roger's to double check their firewall settings but they advise that it's fairy open and so is ours.
I almost suspect that maybe the WAN interface the new IP is on is not routed properly to their LAN interface and this is what is preventing us from browsing behind. Unfortunately, I have no access to that system so am unsure how it's configured.
Maybe also ask Rogers to reset their tunnel.
It may not be a VPN configuration issue. Have you checked the router Firewall rules and Windows or any other software firewall rules. They may have been set to only allow connections to a specific IP or subnet. This is a fairly common security choice by IT admins.
No clue how that should work - you can't just seitch between VPN gateways and expect routing to work. Unless the remote gateway creates routes dynamically based on the Phase 2 IP info exchanged, and I don't think so.
Roger's need to know which gateway is responsible for your LAN IPs. A traceroute performed on both sides should reveal where communication stops. If I'm correct, Roger's still routes to the old WAN IP.
Roger's need to know which gateway is responsible for your LAN IPs. A traceroute performed on both sides should reveal where communication stops. If I'm correct, Roger's still routes to the old WAN IP.
If I'm correct, Roger's still routes to the old WAN IP.
That part is not entirely clear to me. Access to home worked, then it did not work properly for a period, then Rogers changed my IP to a completely different block and it has been working fine ever since. So Rogers configuration, to your point, makes a difference.
That part is not entirely clear to me. Access to home worked, then it did not work properly for a period, then Rogers changed my IP to a completely different block and it has been working fine ever since. So Rogers configuration, to your point, makes a difference.
This question needs an answer!
Become an EE member today
7 DAY FREE TRIALMembers can start a 7-Day Free trial then enjoy unlimited access to the platform.
View membership options
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.
The settings you showed look fine.
Make sure that when you got a new WAN IP that you did not also get the SAME Subnet at Rogers as you have in your local office. That could cause the problem above.
Also try enabling NAT Traversal in Advanced Settings on the local end. Try this both ways.