Topics

1

Virtual private networks / MultiWAN OpenVPN recover after failover

« on: February 15, 2021, 04:14:26 pm »

Hi,

I have a question regarding a Multi-WAN setup and outgoing OpenVPN client connections. As it is not possible to choose the right gateway group as interface with an OpenVPN client, I' ve selected "any" as interface. I configured my gateways with the correct priority and monitoring. In System: Settings: General I've checked "allow default gateway switching".
If the main connection is going down, fallback is working and the OpenVPN connections are coming back up on the failover line.
After the main line is recovered new traffic is again routed through the main connection. The OpenVPN connections however are not reconnecting via the main connection. They keep using the failover connection. If I'm forcing a reload of that connection it's coming up via the main connection. How can I trigger that automatically?

Under Firewall: Settings: Advanced
in Gateway Monitoring I have unchecked: Kill states (Disable State Killing on Gateway Failure)
and in Multi-WAN I have sticky connections checked. Should this be unchecked? Has this any effect on OpenVPN client connections?

Thanks for reading

2

Documentation and Translation / OpenVPN site-2-site documentation is missing something

« on: December 08, 2020, 07:37:50 pm »

Edit: just found: https://docs.netgate.com/pfsense/en/latest/recipes/openvpn-s2s-tls.html

which shows the client-specific override section. It seems as if this is only needed, if you use the SSL/TLS mode of OpenVPN. Maybe that should be noted. Now I know the difference

____

Hi,

I'm referencing to this page:
https://docs.opnsense.org/manual/how-tos/sslvpn_s2s.html

For an OpenVPN site-2-site tunnel the documentation is missing the note that you need a client-specific override on the server side. You configure the remote network twice. Once in the main server config (all remote networks from clients connecting to that server are added there) and second in a client-specific override, where the remote network(s) from that client (mapped through the common name) are listed again. Otherwise you'll see a route in the system routing table but no traffic will be reaching it's target, because the OpenVPN daemon won't know to which client this network belongs and will discard the packet.

3

20.7 Legacy Series / [SOLVED] IPsec tunnel breaks OpenVPN SIP/udp traffic

« on: November 18, 2020, 12:08:32 pm »

Hi,

I have a problem with an OPNsense bare metal box of a client.
Hardware is: ZBOX PRO CI329 nano with Realtek nics. OPNsense 20.7.4

Simple network:
LAN is 10.0.0.0/24
WAN is a static IP, direct ethernet connection
2 OpenVPN servers: TCP&UDP on WAN 1194, having 10.0.1.0/24 and 10.0.2.0/24 for their clients. LAN network is pushed to the client. Everything works great until I enable an IPsec tunnel.

This IPsec tunnel is IKEv1 in main mode and Phase2 is: local LAN 10.0.0.0/24, remote is 84.x.x.x/29. IPsec works like it should, so the LAN reaches the remote side.
 
My client uses a NetPhone Client to connect to the PBX in the LAN (10.0.0.70). No NAT involved. Plain routing.
If the clients are not inside of the office, they work by OpenVPN connection to connect to the PBX.

As soon as I enable the IPsec tunnel the problems start with the OpenVPN connections.

From the live log I can't see any blocked packets. The client is able to be called and is able to make outbound calls. But after max 1 minute the connection is dropped. And this client is not able to see the status of the other employees which are connected to the PBX.

Tried to connect to both OpenVPN (not at the same time of course), problem persists.

In the live log I see UDP connections without source and destination port. Is that maybe a hint? Never seen such connections in my logs before. See attached files.

When I disable the IPsec tunnel everything is running like it should with OpenVPN. Why is an IPsec tunnel disturbing an OpenVPN tunnel? IPsec is policy based. Any ideas?

Maybe we should move this thread to VPN section as it seem to be only VPN related.

And another note:
those creepy connections without source&destination port are also gone. But I need to re-enable the IPsec tunnel soon, so what can I do?

4

20.7 Legacy Series / [Solved] OpenVPN firewall rules

« on: October 03, 2020, 12:27:54 pm »

Hi,

I noticed a strange problem with OpenVPN servers on OPNsense when assigning interfaces to those OpenVPN servers.

There is already a german thread https://forum.opnsense.org/index.php?topic=9150.msg88343#msg88343

When creating an OpenVPN server and assign that server to an interface you´ll get those new interfaces in the Firewall section. I thought it might look better if you separate the rules by interface. Unfortunately rules created there don´t bring the effect you´d expect. The rules are evaluated by traffic flowing through this interface. In the firewall logs you can see that the packets come in from the correct interface and the packets may pass.
But the packets are not leaving the OPNsense anymore. Doesn´t matter if the packets need to be routed or are addressed to services on the OPNsense.

When you move or even clone the same rule to the OpenVPN firewall section packets are flowing like they should.
Something is weird with handling traffic through those assigned interfaces.

Did a packet capture but don´t see any problems here. You see the packets coming in, but not leaving the box.

5

20.7 Legacy Series / [Partly solved] WireGuard with virtual IP

« on: September 27, 2020, 02:15:14 pm »

I was testing a new OPNsense installation (20.7.3). On the WAN interface there are 2 IPs, one via DHCP and one statically added as virtual IP.

Configurred WireGuard on port 51820.

Added a firewall rule to allow incoming packets to port 51920 on the WAN interface.

When I connect to the primary IP connection is coming up.

Connecting to the virtual IP is not successful. I see an incoming packet to the virtual IP on the WAN interface (port 51820), which is accepted. But WireGuard then seems to answer with the wrong IP. I see the outgoing packet from the primary IP and source port 51820. This is of course not accepted by the other side.

Is there a chance to set the interface WireGuard should listen to/answer from?

Thank you.

Edit: tried to fix it with outbound NAT, rewriting connections coming from the primary ip on port 51820 to the virual ip. But this doesn´t work either. Tried with and without tatic port checked.