[Solved] not able to reach outside world through openvpn tunnel

[vigilian]

hi,

this setup is a bit maybe complex but for me it's quite simple in the idea.

I've setup a virtual opnsense setup on a isolated server on one of my VLANs which needs to act as a gateway for other VMs on the same server.

Among some gateways there are the WAN, an openvpn to a vpn provider, a wireguard connection to a vpn provider, a openvpn to a foundation that provides me a routable public address.
 
I have problems with that last one.
This openvpn link I want to make it happen through the wireguard link because I don't want them to record my public ip address among other things.
I "think" I succeeded to do that. At least the connection is happening and I'm receiving the public ipv4 and ipv6 that I was supposed to receive.

--------------part one--------------

But my first question is: How can I be sure that it is indeed well executed through the wireguard tunnel already in place?

second question : When I setup the connection I've configured the field of the interface with the wireguard interface. Is that enough ?

The wireguard tunnel has been executed through the excellent script and tutorial here: https://github.com/FingerlessGlov3s/OPNsensePIAWireguard
As you can see, the wireguard tunnel is done through 2 interfaces( the interface that you will assign the new link and the interface of the subnet(s) you want to link to), or 3 if you count the wireguard service.
As you can see also there is an outbound NAT rule for the 500 port for the IKE protocol and for normal usage for all subnets configured in the firewall, which copies both the rules that are automatically generated for WAN.
third question:
I'm not an expert for that the vpn links in that kind of setup so it surprises me that there is a need for a specific port 500 for that since my openvpn setup of the vpn provider didn't need that to make it work. So if someone has documentation or an explanation to give me about that that would be nice 

--------------part two--------------

I don't have communication apparently through the tunnel.
I have deactivated from the original script the pull option which might be the reason because then I guess all routes are not in there but I need your insight for that. And I did that because I was using the pull method then it would screwed my wireguard connection, pull it down, and then go back up because of the script put in place and the monitoring but not the openvpn connection of course.

so first question is : is it because of the absence of the pull option and if yes, how to resolve that?

I can't even ping from the firewall itself using the -S switch of the ping command.

I've tried to reproduce the rules fr the outbound NAT as described here: https://forum.opnsense.org/index.php?topic=4979.0

in place of alias I've tried with any and also with the pre-configured alias of the subnet that I was linking to it. You know the ones that are created when you create an interface, you have always the the interface address entry and the one with the name interface net

I've put a rule also in the firewall to let the traffic goes through it.

So what should I provide as logs? as screenshot maybe ? How can I help to make it determine what's the issue here?


We could say that the part of the openvpn link would ressemble to that schematic.
Where the subgateways are there for handling dhcp, routing to the good interface, portforwarding with outside LAN and so also some NAT and can be linked to the appropriate gateways I want for each subnet.
Maybe it's not the way it should be but that's the more appropriate way I could find to compartimentalize.

I then know that the problem does not reside into the subgateways since it is working with all the other gateways. So I wouldn't understand why not for this one unless you explain it to me.
So I must miss something on the ovpn gateway.
I'm pretty sure this is possible since I'm used to qubes and even if it's a bit of a difference since it's handled by VM's for each connection, it means nevertheless that it is possible.

Thanks for all the help you can give me.

[vigilian]

okey I've succeeded to find the problem to it.

2 things actually,

• a virtualization problem where there was a problem in applying rules of forwarding packets apparently. There is some differences from what you choose, if it's a bridge or a macvlan interface... Depending of your qemu version and how you configured your different internal network and main interface you could encounter some problems. Some examples of configuraitons :https://blog.scottlowe.org/2016/02/09/using-kvm-libvirt-macvtap-interfaces/
• The other thing was the gateways and their priorities. The fact that normally you should be behind the firewall and not in front, organizes the interfaces in specific ways. It's being told in many threads about it. But so it means also that it organizes the priorities of the gateways not in the best way possible for this specific setup.
  In this case, it had kept a LANvm interface which was the secondary interface as the main gateway and active. While the WAN interface was kept at a lower place in term of priority.
  Deleting the LANvm gateway and putting the WAN interface as the first place and deleting other useless potential gateways even deactivated, was teh way to go.

A side note for this second problem, the netflow tool or even the tcpdump was registering packets going through the good vpn interface. I had to ask people on the other end of the link to do a tcpdump to see if packets were coming through and it was not.
So it means that even if tcpdump does show you something, the routing aspect can be much lower in that specific case in the kernel scale and so you won't be able to diagnose this the usual way.


I can also confirm that the vpn link can go through the wireguard tunnel.
That pfsense topology option in the client configuration is actually a server side option as shown in the openvpn documentation https://community.openvpn.net/openvpn/wiki/Topology?__cf_chl_jschl_tk__=6a3f3249ad65cb388ebae5943a61adc70d8c3f72-1618305770-0-AXaURhXgeaZUm_Y8t-UsspsvMRFjMVxNhb2q9pXmpMX8mgSU9GfOTLiZcyTD5Aciv5k7u6KCb6fAqghPymykGiKC-PZoiK71t06XhGvEpblQo1aMLQ3B6uueozRVfvozf5h97_Htn6_fbl_S3q5S-vtdsnScG20W2bl9JxlaGfBswSYn5xRTWCd0sktXhvRmD9UytfNlop6TpQTGvYr7g-cJIkhPsXX602cc4lQVKUJCfyJi7gfQ2R8QtEvPcm05P-86u8q79yTZ4udokKK6a4z9rgJv-hNHp3nJXPnRtNa497gM5QkSq2JXMGxbtpdR1ol2ILlycSqhnM1-8pONPLIwmbW-ARunWuxb1kEqHxYVUcXBdxFDtLGRYjNblHvAezs8YDuaIAtCpFIO4zlgKUM