Devices behind a remote WG unreachable since 12.5.3 update
Hi everyone,
I'd appreciate your feedback n my issue.
We have two remote sites:
1. Site 1: WG M200
- WS 2016 host with several VMs incl RDS farm, DC with DNS 192.168.16.253 etc
- Offices 192.168.16.0 network
2. Site 2: WG M370 (upgraded from M200)
- Offices 192.168.254.0, 10.2.8.0, 10.2.7.0, 10.2.254.0 VLANs
Both firewalls configured correctly with all required tunnels.
So last Wednesday, I replaced the M200 at Site 2 to M370 and updated the OS to 12.5.3 U1 on it. All worked fine until I realised I couldn't VPN from home to Site 1 any more, but not until I switched the servers over the last weekend. The new DNS IP is 10.2.7.50.
Both firewalls DNS/auth settings have been updated to point to the new DC/DNS IP. Basically, all VMs were shut down at Site 1 and Site 2 became the main site running our VM servers (ADFS, DC, FP, RDS etc).
When I was testing all this before and whilst on M200s at both sites, I was able to connect to both firewalls from home via Mobile VPN. Both firewalls were correctly communicating with the new DC/DNS server with a new IP at Site 2.
Site 1 & 2 FWs were connected to DNS 10.2.7.50 and the domain controller was reachable. VPN authentication worked fine.
Then I replaced M200 with M370 at Site 2, updated it to 12.5.3, then launched the VMs and realised I couldn't connect to Site 1 anymore.
It turns out that the firewall at Site 1 is no longer able to reach any devices outside of the firewall at Site 2 and vice versa. It seems like the issue is related to the OS update.
All devices at Site 1 and 2 can communicate properly and everything else works as it should, but neither of the firewalls cannot communicate with devices outside of the firewalls, which includes the new DC/DNS IP - hence why VPN authentication fails when trying to connect to Site 1 VPN. I can connect with my Firebox username, but not a domain account.
I'm not 100% sure it is to do with the OS update, but I didn't change any other configs on neither of the firewalls.
Up until Tuesday, both sites were running WG M200 with 12.2.1 OS. Both were configured for BOVPN and Mobile VPN with SSL.
I updated M200 at Site 1 to 12.5.3 U1, but it didn't make any difference.
What has changed in the 12.5.3 OS that would prevent the firewalls from communicating with other devices?
Anything else I should be checking?
Comments
Consider opening a support incident on this.
What kind of VPN connection is this from your home? IPSec Mobile VPN?
What is the DNS IP addr that you get for this VPN type when connected to each of the remote firewalls?
"It turns out that the firewall at Site 1 is no longer able to reach any devices outside of the firewall at Site 2 and vice versa."
Is this connection attempt via IP addrs?
Can you ping/tracert to 10.2.7.50 from something at remote site 1 ?
You can do a ping from WSM Firebox System Manager -> Tools -> Diagnostic Tasks, or the Web UI -> System Status -> Diagnostics -> Network.
Use the -I interface Advanced Option and specify a Trusted interface name, such as eth2
Nothing in either firewall logs/Traffic Monitor to help understand this?
It is a Mobile VPN with SSL. Yes I can ping DNS server from Site 1 devices to Site 2.
Pinging 10.2.7.50 from within the FIrebox results in 100% packet loss. I can ping devices at Site 1 from within the firebox at Site 1 and I can ping devices at Site 2 from within the firebox at Site 2.
The only thing I'm getting from traffic monitor is when I try connecting to VPN from home - it just says authentication server (the domain controller in this case) is unreachable.
I am getting a response from a trusted interface
PING 10.2.7.50 (10.2.7.50) from 10.1.254.1 eth1: 56(84) bytes of data.
64 bytes from 10.2.7.50: icmp_seq=1 ttl=126 time=3.72 ms
64 bytes from 10.2.7.50: icmp_seq=2 ttl=126 time=3.76 ms
64 bytes from 10.2.7.50: icmp_seq=3 ttl=126 time=3.75 ms
and
PING 10.2.7.50 (10.2.7.50) from 10.1.254.1 eth3: 56(84) bytes of data.
64 bytes from 10.2.7.50: icmp_seq=2 ttl=126 time=3.94 ms
64 bytes from 10.2.7.50: icmp_seq=3 ttl=126 time=3.73 ms
64 bytes from 10.2.7.50: icmp_seq=4 ttl=126 time=3.67 ms