OPNsense Forum
English Forums => Virtual private networks => Topic started by: rbed on September 11, 2021, 05:08:46 pm
-
Hey there, I just signed up to find some help with my VPN. My networking knowledge is very limited and hopefully it's just a silly mistake that I've made.
I've found a couple very similar threads but none of the solutions worked for me. Please poke me if I'm supposed to pick up one of them.
https://forum.opnsense.org/index.php?topic=13536.0
https://forum.opnsense.org/index.php?topic=14970.0
---
I'm trying to establish a VPN between our on-prem network (datacenter DC) and the Google Cloud Platform (GCP). Actually, the tunnel is set up and connected and I can ping from the GCP side. The ping from the DC side remains unanswered. They aren't blocked by the FW and when I capture the traffic, I actually see requests and (!) responses. But apparently they don't reach the original machine.
I have a fresh OPNsense 21.7.2_1-amd64 (x.x.x.99) installation. I have three gateways, a default one (the machine isn't the default gateway for the network, that's x.x.x.65), another one called LAN_GW (I don't know why / what's the difference) and the far gateway pointing at the GCP end. (See attachment)
Then I have a route just for a single test VM in the GCP (See attachment) - 10.255.255.250/32 via the GCP_Gateway.
The VPN itself is established (see more attachments).
FW rules are in place to allow all outgoing traffic to 10.0.0.0/8 and incoming as well, IPsec + LAN, just to be sure.
Since the OPNsense x.x.x.99 isn't the default gatway I added a route on a VM in DC and when I traceroute 10.255.255.250 I can see that the first hop is in fact x.x.x.99.
Package capture shows requests and replies for my pings for interface "ix3" and "enc0". I have no idea what "enc0" is but I guess it belongs to the IPsec tunnel. It's nowhere to be found in the GUI. Or I'm stupid - that's always a valid option.
I wonder how my "GCP_Gateway" is supposed to know that it's the traffic shall be sent via IPsec. The only interface I can pick in the gateway settings is "LAN" ... In the guide (https://docs.opnsense.org/manual/how-tos/ipsec-s2s-route.html) they pick an interface "IPSEC1000".
I hope my mistake is obvious to someone and that someone is willing to enlighten me ;)
---
What I've tried from answers to similar questions so far:
- Fiddle around with the NAT outbound settings.
- Uncheck "Install policy" in the tunnel settings.
- Playing around with gateway priorities.
-
enc0 is a virtual IPsec interface
-
enc0 is a virtual IPsec interface
Ah thanks, that's what I've thought. Then I'd figure that the ICMP packet comes in, gets routed to the VPN tunnel, a reply comes back but then is lost somewhere? :|
-
GCP is route based IPsec, you need a different guide, like Azure
-
GCP is route based IPsec, you need a different guide, like Azure
Do you have one you can link?
/edit: https://docs.opnsense.org/manual/how-tos/ipsec-s2s-route-azure.html ?
-
Yep .. most important is "Install Policy" checkbox.
Dont have it ticked while changing P2 to route-based .. it will kick you out when you access it remote
-
Sadly, the guide has
Step 3 - Set MSS Clamping
(Under Interfaces ‣ IPsec Azure) We will use the following settings:
But there is no such (equivalent) iface - where should it come from? I only have LAN and OPT1 (whatever that is). :/
Plus, there's also an iface "IPSEC1000" in this guide and I have no idea where it comes from.
-
Additional bit of information: In my actual gateway/FW I see block events for 10.255.255.250 -> x.x.x.111 but not vice versa. Why is that?
If the traffic goes through the tunnel I shouldn't see it here. If it does not, I should not see any. It looks like the request DC -> GCP goes past the firewall but the response does not ...
My default DC gateway/FW is x.x.x.65. The tunnel runs on x.x.x.99
-
The description of your vpn will be name of the ipsec interface. If it's empty you'll have ipsec1000. Just look for the description. If there is no interface you config is not correct.
-
The description of your vpn will be name of the ipsec interface. If it's empty you'll have ipsec1000. Just look for the description. If there is no interface you config is not correct.
Thanks for the quick reply! Any idea what might not be "correct"?
And what's the deal with 10.111.1.1 / 10.111.1.2 in the Azure guide? What's their purpose? I'm not quite sure where to put the one on the GCP end.
-
no, these IPs are only local to your opnsense.
Can you post screenshots please?
-
Can you post screenshots please?
Sure, of what exactly?
-
Interfaces : Overview, IPsec Phase1 and Phase2 details
-
Here's the original setup that works one-way.
The tunnel has "install policy" checked - without it, I can't ping GCP -> DC.
/edit: only 4 attachments allowed, need to split the post
-
enable policy checked
-
Tunnel details for the Azure guide setup
-
LAN is the only interface (I deleted the weird OPT1)
-
Why only the LAN? Shouldn't it be WAN? Is this the GCP box or on-prem?
And why respond only? Also /128 looks weird
-
The OPNsense VPN Gateway (.99) is not the default gateway (that's .65).
There Azure guide https://docs.opnsense.org/manual/how-tos/ipsec-s2s-route-azure.html had "respond only" in it, that's why.
I was wondering about the /128, too, but I cannot change it.
-
Some more intel:
I see the traffic DC -> GCP coming through in the FW logs on .99. I can also see it in the FW logs within the GCP in the allow-ingress rule I've set up.
I can then also see traffic going back within the GCP but apparently it's lost after that.
-
I need a Network diagram including IP addresses to fully understand this setup
-
Here's one. I hope that helps.
Actually I'm not 100% sure whether or not .99's traffic is passing through .66 or not.
-
When .65 gateway of .66 is, why .99? I dont get it
-
That's the not so well documented setup I inherited. The .99 is there because we didn't want to mess around with our live FW.
-
Please use real IPs and changing only one bit, really, noone is interested in your network :) someone around the globe is always scanning it
-
Apparently the wrong route was chosen on the way back from the tunnel and then the response was eaten by the bridging firewall.