Weird IPSec tunnel issue - Virgin?

Vertigo

Vertigo

Vertigo

Soldato
Joined
28 Dec 2003
Posts
16,576
Got a strange issue trying to configure a site-to-site IPSec tunnel between my own firewall (pfSense) and a remote site using a Watchguard Firebox.

Everything appears configured correctly but the tunnel won't even establish, with both ends reporting no response to the IKE_SA_INIT, as if they can't even see each other.

Thing is, when I check the live traffic and/or diagnostic logs, there's no sign that the other end's communication is even arriving at the firewall at all, which leads me to wonder if Virgin have started blocking something?

Anyone had anything similar?
 
Are you absolutely certain you’ve got the IP addresses right on both ends? I’ve picked up a few escalations where this has been the problem.

Have you got logging enabled on the Watchguard VPN policy? If not, you won’t see anything in the live traffic logs for allowed packets. Better to do a TCP dump on the WAN interface instead. Send a ping whilst you’ve got the dump running - if you don’t see that, the IP is wrong.

I have heard Virgin heavily shape IPSEC traffic, but I don’t believe they block it completely.
 
Yep both endpoint addresses are definitely correct.

I've set IKE logging to 'Info' but not full-blown 'Debug' and there's just no sign of anything from the other end in the Traffic Monitor. I actually did a traceroute from within pfSense at the other end and that showed up fine in the monitor.

All the symptoms and diagnostics I've done point to VM blocking it but I can't believe they actually would. Given the proliferation of these VPN services for circumventing geo lockouts on streaming services and how the ISPs are trying to block them, I wondered whether maybe they'd tried doing something at the protocol level rather than just blocking sites.
 
Ok, progress!

Our primary connection at the office is a synchronous fibre line from Glide and it was this I was using.
We also have a secondary line from Virgin Media Business but this is just a 'business' version of their domestic cable modem service so just a 500/35 connection for cheap. We use this as a backup and for non-essential traffic like employees mobiles, guest Wifi etc etc.

I just tried shunting the tunnel over to the VM line and it works!!

This suggests Glide are doing some kind of blocking or filtering on what should be an unadulterated connection. Will get onto them.
 
Spent a while going back and forth with them and it looks like their supplied Zyxel box is the root cause.

This is configured in a kind of hybrid mode whereby it's doing the PPPoE authentication but NAT is disabled. This has always worked fine until recently.

Whilst I suspect a reboot might actually clear the problem as it's been up for nearly two years, their tech and I have agreed it should really be in full bridge mode anyway with the Watchguard doing the PPPoE.

Going to pop into the office in the morning to effect the change and see what happens.
 
It's just their standard terminating router which has a fibre WAN connection and Ethernet LAN.

I presume most customers just use that as their only router/firewall but we just have everything passed through to our own device.
I can't remember exactly how the fibre connects into it but it's not SFP. Our Watchguard doesn't have SFP connections anyway.

In the morning I'm going to get them to switch it into proper bridge mode so it's just doing media conversion from fibre to Ethernet and reconfigure the Watchguard for PPPoE.
I'm hoping that will solve the issue I'm having but, even if it doesn't, it's how it should be configured really.
 
So I chickened out of the switch to full bridge mode today :)

On closer inspection, it seems the Zyxel is obtaining a single IP address via PPPoE and then routing our actual /29 subnet through that single IP. Whilst the Zyxel is in "routing" mode, NAT is disabled so it just passes the subnet through on the LAN side.
The Watchguard interface is then just configured as Static IP with the correct subnet configured and voila.

What I'm not sure about is how to configure the Watchguard to do the same thing. All my research indicates that I should just put the interface in PPPoE mode and it'll then obtain the same single IP address, then I can configure our subnet as secondary addresses and it should work like the Zyxel does.
Thing is I've never tried this before and am wary about screwing something up so I'm going to hold off for the moment as it's not mission critical right now.
There's also a concern about messing with the configuration of the Zyxel as it's not our device and I don't really want to end up locking myself out of it and having to factory reset and reconfigure etc etc.

I have pretty much proven to Glide that there is an issue whereby the initial IKE packets on UDP port 500 are being blocked, either by their network or the Zyxel, and they're investigating so I'll await the results of that.

Lastly, upon checking the Zyxel, it does actually have a standard SFP port on the back, housing a BiDi module connected to a single fibre.
As a result, when I do decide to mess with this, I think I'm going to grab an SFP to Ethernet media converter so I can just bypass the Zyxel completely and feed directly into the Watchguard. Cleaner and means I don't have to mess with the Zyxel itself and can just re-insert it if I need to backtrack.
 
You should just be able to use your public IPs in NAT rules on the Watchguard and as long as you are sending the traffic out the correct interface it should all Just Work. I have limited Watchguard experience but this is how every other firewall I've touched works.

The only thing I am not sure about is whether you can use those addresses for traffic originating from the firewall - e.g. in IPsec tunnels, or whether you need to use the address allocated to the interface via PPPoE.
 
Yeah I'm sure it's possible to make it work but may well require a bit of reconfiguration and general faffing about rather than just a drop-in change.
 
You must log in or register to reply here.
Back
Top Bottom