Show Posts
1
General Discussion / No remote LAN access with Site-to-Site OpenVPN connection, please help.
« on: May 30, 2024, 11:44:58 am »
Hello everyone,
I am trying to establish a Site-to-Site OpenVPN connection between pfSense 2.7.2 and OPNsense 24.1.8 and encountering issues that I cannot explain. So far, I have only worked with pfSense and never had such a problem. I hope you can help me!
The OpenVPN connection is up!
This is the client (OPNsense) side log:
This is the server (pfSense) side log:
The tunnel network is 10.10.100.0/24, the server (10.10.100.1) can ping the client (10.10.100.2). I have entered the server's local network (172.16.50.0/24) under "IPv4 Local network(s)" on the server, as well as the client's remote network (192.168.8.0/24) under "IPv4 Remote network(s)" on the server. As can be seen from the logs, the routes are also being pushed. When I check the routing table on both sides, a route for the LAN of the opposite side leads into the VPN tunnel. So much for routing!
Routes on the server:
Routes on the client:
Afterwards, I created an interface for the OpenVPN connection on both the server and client, activated it, and created a rule on this interface to allow everything through. I also tested this rule on the general OpenVPN tabs in the firewall, but that didn't help.
As shown in the attached screenshot, I can reach the tunnel endpoint on the server and the server's LAN from the client as long as I use the tunnel IP of the client as the source. As soon as I use a LAN IP of the client as the source, nothing works anymore.
From the server's perspective, it looks like this:
10.10.100.1 > 10.10.100.2 = works
172.16.50.1 > 10.10.100.2 = works
10.10.100.1 > 192.168.8.1 = does not work
172.16.50.1 > 192.168.8.1 = does not work
I really have no idea what the problem could be, as the routes on both sides are correct, the connection itself is working, and the firewall rules are absolutely identical.
The only thing that makes me suspicious is that in OPNsense all the default rules are shown above the rule I created. But that "just looks like that", right?
On the client under VPN > OpenVPN > Connection Status > Routes is no entry, even if I add the "IPv4 Remote Network" that is already pushed by the server anyway. Is that normal? For what is this tab?
I am trying to establish a Site-to-Site OpenVPN connection between pfSense 2.7.2 and OPNsense 24.1.8 and encountering issues that I cannot explain. So far, I have only worked with pfSense and never had such a problem. I hope you can help me!
The OpenVPN connection is up!
This is the client (OPNsense) side log:
Code: [Select]
Protocol options: protocol-flags cc-exit tls-ekm dyn-tls-crypt
Timers: ping 10, ping-restart 60
Data Channel: cipher 'AES-256-GCM', peer-id: 0
Initialization Sequence Completed
/sbin/route add -net 172.16.50.0 10.10.100.1 255.255.255.0
/usr/local/etc/inc/plugins.inc.d/openvpn/ovpn-linkup ovpnc1 1500 0 10.10.100.2 255.255.255.0 init
/sbin/ifconfig ovpnc1 10.10.100.2/24 mtu 1500 up
TUN/TAP device /dev/tun1 opened
TUN/TAP device ovpnc1 exists previously, keep at program end
ROUTE_GATEWAY 192.168.0.1/255.255.255.0 IFACE=vtnet0 HWADDR=bc:24:11:23:cb:df
OPTIONS IMPORT: tun-mtu set to 1500
OPTIONS IMPORT: route-related options modified
OPTIONS IMPORT: route options modified
OPTIONS IMPORT: --ifconfig/up options modified
PUSH: Received control message: 'PUSH_REPLY,route 172.16.50.0 255.255.255.0,route-gateway 10.10.100.1,topology subnet,ping 10,ping-restart 60,ifconfig 10.10.100.2 255.255.255.0,peer-id 0,cipher AES-256-GCM,protocol-flags cc-exit tls-ekm dyn-tls-crypt,tun-mtu 1500'
TLS: tls_multi_process: initial untrusted session promoted to trusted
TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
[BLABLA_OpenVPN] Peer Connection Initiated with [AF_INET]*ServerIP*:2024
Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bits RSA, signature: RSA-SHA256, peer temporary key: 253 bits X25519
VERIFY OK: depth=0, CN=BLABLA_OpenVPN, C=DE
VERIFY EKU OK
++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Validating certificate extended key usage
VERIFY KU OK
VERIFY OK: depth=1, CN=Lighthouse_CA, C=DE
TLS: Initial packet from [AF_INET]*ServerIP*:2024, sid=35902d0a 5dc1c0bf
UDPv4 link remote: [AF_INET]*ServerIP*:2024
UDPv4 link local (bound): [AF_INET]192.168.0.24:0
Socket Buffers: R=[42080->42080] S=[57344->57344]
TCP/UDP: Preserving recently used remote address: [AF_INET]*ServerIP*:2024
NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
MANAGEMENT: unix domain socket listening on /var/etc/openvpn/client1.sock
library versions: OpenSSL 3.0.13 30 Jan 2024, LZO 2.10
OpenVPN 2.6.10 amd64-portbld-freebsd13.2 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD]This is the server (pfSense) side log:
Code: [Select]
BLABLA/*ClientIP*:43618 Protocol options: explicit-exit-notify 1, protocol-flags cc-exit tls-ekm dyn-tls-crypt
BLABLA/*ClientIP*:43618 Timers: ping 10, ping-restart 120, inactive 300
BLABLA/*ClientIP*:43618 Data Channel: cipher 'AES-256-GCM', peer-id: 0
BLABLA/*ClientIP*:43618 SENT CONTROL [BLABLA]: 'PUSH_REPLY,route 172.16.50.0 255.255.255.0,route-gateway 10.10.100.1,topology subnet,ping 10,ping-restart 60,ifconfig 10.10.100.2 255.255.255.0,peer-id 0,cipher AES-256-GCM,protocol-flags cc-exit tls-ekm dyn-tls-crypt,tun-mtu 1500' (status=1)
BLABLA/*ClientIP*:43618 MULTI: primary virtual IP for BLABLA/*ClientIP*:43618: 10.10.100.2
BLABLA/*ClientIP*:43618 MULTI: Learn: 10.10.100.2 -> BLABLA/*ClientIP*:43618
BLABLA/*ClientIP*:43618 MULTI_sva: pool returned IPv4=10.10.100.2, IPv6=(Not enabled)
*ClientIP*:43618 [BLABLA] Peer Connection Initiated with [AF_INET]*ClientIP*:43618
*ClientIP*:43618 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bits RSA, signature: RSA-SHA256, peer temporary key: 253 bits X25519
*ClientIP*:43618 TLS: tls_multi_process: initial untrusted session promoted to trusted
*ClientIP*:43618 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
*ClientIP*:43618 peer info: IV_COMP_STUBv2=1
*ClientIP*:43618 peer info: IV_COMP_STUB=1
*ClientIP*:43618 peer info: IV_LZO_STUB=1
*ClientIP*:43618 peer info: IV_PROTO=990
*ClientIP*:43618 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305
*ClientIP*:43618 peer info: IV_NCP=2
*ClientIP*:43618 peer info: IV_MTU=1600
*ClientIP*:43618 peer info: IV_TCPNL=1
*ClientIP*:43618 peer info: IV_PLAT=freebsd
*ClientIP*:43618 peer info: IV_VER=2.6.10
*ClientIP*:43618 VERIFY OK: depth=0, CN=BLABLA, C=DE
*ClientIP*:43618 VERIFY SCRIPT OK: depth=0, CN=BLABLA, C=DE
*ClientIP*:43618 VERIFY EKU OK
*ClientIP*:43618 ++ Certificate has EKU (str) TLS Web Client Authentication, expects TLS Web Client Authentication
*ClientIP*:43618 Validating certificate extended key usage
*ClientIP*:43618 VERIFY KU OK
*ClientIP*:43618 VERIFY OK: depth=1, CN=BLABLA_CA, C=DE
*ClientIP*:43618 VERIFY SCRIPT OK: depth=1, CN=BLABLA_CA, C=DE
*ClientIP*:43618 VERIFY WARNING: depth=1, unable to get certificate CRL: CN=BLABLA_CA, C=DE
*ClientIP*:43618 VERIFY WARNING: depth=0, unable to get certificate CRL: CN=BLABLA, C=DEThe tunnel network is 10.10.100.0/24, the server (10.10.100.1) can ping the client (10.10.100.2). I have entered the server's local network (172.16.50.0/24) under "IPv4 Local network(s)" on the server, as well as the client's remote network (192.168.8.0/24) under "IPv4 Remote network(s)" on the server. As can be seen from the logs, the routes are also being pushed. When I check the routing table on both sides, a route for the LAN of the opposite side leads into the VPN tunnel. So much for routing!
Routes on the server:
Code: [Select]
10.10.100.0/24 link#8 U 6 1500 ovpns2
10.10.100.1 link#4 UHS 9 16384 lo0
192.168.8.0/24 10.10.100.2 UGS 10 1500 ovpns2Routes on the client:
Code: [Select]
ipv4 10.10.100.0/24 link#8 U NaN 1500 ovpnc1 OpenVPN
ipv4 10.10.100.2 link#8UHS NaN 16384 lo0 Loopback
ipv4 172.16.50.0/24 10.10.100.1 UGS NaN 1500 ovpnc1 OpenVPNAfterwards, I created an interface for the OpenVPN connection on both the server and client, activated it, and created a rule on this interface to allow everything through. I also tested this rule on the general OpenVPN tabs in the firewall, but that didn't help.
As shown in the attached screenshot, I can reach the tunnel endpoint on the server and the server's LAN from the client as long as I use the tunnel IP of the client as the source. As soon as I use a LAN IP of the client as the source, nothing works anymore.
From the server's perspective, it looks like this:
10.10.100.1 > 10.10.100.2 = works
172.16.50.1 > 10.10.100.2 = works
10.10.100.1 > 192.168.8.1 = does not work
172.16.50.1 > 192.168.8.1 = does not work
I really have no idea what the problem could be, as the routes on both sides are correct, the connection itself is working, and the firewall rules are absolutely identical.
The only thing that makes me suspicious is that in OPNsense all the default rules are shown above the rule I created. But that "just looks like that", right?
On the client under VPN > OpenVPN > Connection Status > Routes is no entry, even if I add the "IPv4 Remote Network" that is already pushed by the server anyway. Is that normal? For what is this tab?