Messages

1

General Discussion / Re: openVPN Server --> Inactivity timeout (--ping-restart), restarting

« on: January 09, 2022, 09:04:31 pm »

Hi,

I came across the same situation with a slightly different authentication setup (Certificate + LDAPS).
After one hour of VPN inactivity, the user is asked for re-authentication. I suppose it is related to the auth-nocache setting in the client config, since the setting forbids to cache the password and therefor the OpenVPN cannot re-authenticate without asking the user.

Long story short, removing auth-nocache should do the trick.

Cheers

2

Virtual private networks / Re: Route from OpenVPN (ovpns2) to policy-based IPSec (enc0)

« on: December 16, 2021, 03:31:10 pm »

Hi all,

I finally made it happen, it works. 

As announced earlier, I switches the IPSec VPN setup from policy-based to route-based. I pretty much followed this guideline here, which 99% did the job for establishing a route-based (VTI) IPSec VPN a OPNsense router and an Azure VPN Gateway:

https://docs.opnsense.org/manual/how-tos/ipsec-s2s-route-azure.html

However, there is a little mistake in the documentation, which I would like to correct here.

In section Step 4 - Azure: Setup local network gateway it states:

Code: [Select]

Address space  |  10.111.1.1/32  |  Local Tunnel IP

However, 10.111.1.1/32 does not make sense at this point, since would mean that the Azure local network gateway cannot reach the remote tunnel IP.
If configured like this, the setup does not work. The IPSec VPN comes up but the static route is not added to the OS routing table, since the remote tunnel IP is not reachable, for obvious reasons. The correct solultion is to configure the Azure local network gateway as follows:

Code: [Select]

Address space  |  10.111.1.0/30  |  Local Tunnel IP

This assures that the Azure VPN gateway can reach the remote tunnel IP. With the example IP addresses, the correct settings in the IPSec phase2 config are:

• Local Address: 10.111.1.1
• Remote Address: 10.111.1.2

These are the two addressable IP addresses from the specified subnet 10.111.1.0/30.

Hope that helps and maybe someone from here can assure that the official documentation is updated accordingly.

3

Virtual private networks / Re: Route from OpenVPN (ovpns2) to policy-based IPSec (enc0)

« on: December 13, 2021, 10:00:18 am »

Hi, thank you very much for your reply.

So what you are saying is that I need to re-configure the IPSec between Site A and Site B:



So basically switching the IPSec phase2 mode from "Tunnel IPv4" to "Route-based", correct.

I hope this is supported by the Azure VPN-Gateway.

Just for reference, I created a high-level drawing to visualize the described situation:

4

Virtual private networks / Route from OpenVPN (ovpns2) to policy-based IPSec (enc0)

« on: December 12, 2021, 04:06:40 pm »

Hello folks,

just registered in the forum, since I have a problem, which I did not manage to solve yet, even after hours of googling.

First of all I will give some background about my setup:

Site A: Azure Cloud (Azure VPN Gateway) 172.16.0.0/16
Site B: Central VPN Aggregator with OPNSense (no dedicated VPN network, VPN router only)
Site C: Branch Office with pfSense Router 10.13.42.0/24

Here is how the sites are be connected)

SiteA (172.16.0.0/16) <--- IPSec ---> SiteB <--- OpenVPN ---> SiteC (10.13.42.0/24)
The networks 172.16.0.0/16 and 10.13.42.0/24 are not configured as LAN on SiteB but only in the IPSec and OpenVPN config accordingly.

My goal is that clients from 172.16.0.0/16 can reach clients in 10.13.42.0/24 and vica versa via the central VPN aggregator (SiteB)

The VPNs are established and working but unfortunately the traffic is not routed from the OpenVPN to the policy-based S2S IPSec. To debug the VPN setup (routing), I initiated a ping from a client in Site A (172.16.0.0/16). The ICMP packets are routed as expected at least on the way from SiteA to SiteB to SiteC but getting stuck at SiteB on the way back:

As said, I pinged a client [10.13.42.1 (pfSense Router)] at SiteC from a client in SiteA (172.16.2.4). The packet capture at SiteB looks as follows:


As you can see, the packet reaches SiteC, an according response is sent (echo reply) but then the reply gets stuck a SiteB, since it is not routed to the IPSec VPN to SiteA.

Firewalls for IPSec and OpenVPN are widely open (pass any), so that it is not a firewalling issue. Based on some google research, I added a 2nd phase2 between SiteA and SiteB, so that the internal OpenVPN transfer network (10.1.2.0/30) is known by the IPSec but this does not seem to do the trick. However, not make sense in my opinion anyway.

I am quite confident that the traffic gets stuck on the way back, since the packets (echo reply) is not routed from the OpenVPN to the policy-based site-to-site IPSec between Site B and Site A.

However, I have no idea how to sovle that?