@pippin The link was very infomative ... but before I change my LAN & Tunnel IP:s there is one thing confusing me. In my old case I had Tunnel IP:s 192.168.2.1/24 and therfore OpenVPN should get an IP 192.168.2.x. When I connected my laptop to OpenVPN server I got following ... [forsete@rk-dell: ~]> ip address 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp4s0u2u4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff 3: wlp0s20f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 3c:e9:f7:b6:68:ae brd ff:ff:ff:ff:ff:ff inet 192.168.158.232/24 brd 192.168.158.255 scope global dynamic noprefixroute wlp0s20f3 valid_lft 3574sec preferred_lft 3574sec inet6 fe80::f6d2:b32f:7645:2fda/64 scope link noprefixroute valid_lft forever preferred_lft forever 5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500 link/none inet 192.168.2.5/24 brd 192.168.2.255 scope global noprefixroute tun0 valid_lft forever preferred_lft forever inet6 fe80::61e7:5d0:9b6d:2810/64 scope link stable-privacy valid_lft forever preferred_lft forever Making ping gave me following ... [forsete@rk-dell: ~]> ping 192.168.2.1 PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data. 64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=43.5 ms ^C --- 192.168.2.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2004ms rtt min/avg/max/mdev = 32.680/36.557/43.492/4.915 ms [forsete@rk-dell: ~]> ping 192.168.2.2 PING 192.168.2.2 (192.168.2.2) 56(84) bytes of data. From 192.168.2.1 icmp_seq=1 Redirect Host(New nexthop: 192.168.2.2) 64 bytes from 192.168.2.2: icmp_seq=10 ttl=63 time=130 ms ^C --- 192.168.2.2 ping statistics --- 10 packets transmitted, 10 received, +10 errors, 0% packet loss, time 9014ms rtt min/avg/max/mdev = 84.506/146.639/258.837/52.247 ms [forsete@rk-dell: ~]> ping 192.168.2.3 PING 192.168.2.3 (192.168.2.3) 56(84) bytes of data. From 192.168.2.1 icmp_seq=1 Redirect Host(New nexthop: 192.168.2.2) ^C --- 192.168.2.3 ping statistics --- 4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3005ms [forsete@rk-dell: ~]> ping 192.168.2.4 PING 192.168.2.4 (192.168.2.4) 56(84) bytes of data. From 192.168.2.1 icmp_seq=1 Redirect Host(New nexthop: 192.168.2.2) ^C --- 192.168.2.4 ping statistics --- 2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1002ms [forsete@rk-dell: ~]> ping 192.168.2.5 PING 192.168.2.5 (192.168.2.5) 56(84) bytes of data. 64 bytes from 192.168.2.5: icmp_seq=1 ttl=64 time=0.089 ms ^C --- 192.168.2.5 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3109ms rtt min/avg/max/mdev = 0.029/0.066/0.098/0.028 ms [forsete@rk-dell: ~]> ping 192.168.2.6 PING 192.168.2.6 (192.168.2.6) 56(84) bytes of data. ^C --- 192.168.2.6 ping statistics --- 3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2002ms Additional information [forsete@rk-dell: ~]> sudo route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.2.1 0.0.0.0 UG 50 0 0 tun0 0.0.0.0 192.168.158.81 0.0.0.0 UG 600 0 0 wlp0s20f3 98.128.190.194 192.168.158.81 255.255.255.255 UGH 50 0 0 wlp0s20f3 192.168.2.0 0.0.0.0 255.255.255.0 U 50 0 0 tun0 192.168.158.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp0s20f3 192.168.158.81 0.0.0.0 255.255.255.255 UH 50 0 0 wlp0s20f3 So what is my laptop IP in the Tunnel ... 192.168.2.1 or 192.168.2.5? Ping to other 192.168.2.x gave ... Redirect Host(New nexthop: 192.168.2.2)

Thanks @jimp - I found bug 13424 referenced at https://blog.nuvotex.de/pfsense-crl-has-expired/ and the patch fixed it.

@uknewituncle [image: 1672852421143-error-pfsense01.jpg] [image: 1672852426574-error-pfsense02.jpg]

@viragomann thank you once again; I've made it. I deleted all my previous configs and started again. The problem was declaring the VPN tunnel on my pfsense client configuration. Since the server has been set to dynamically provide IP addresses through the VPN tunnel, I think it conflicted somehow. Just for anybody else facing this issue, I've managed it in this way: SERVER SIDE: [image: 1672831161583-schermata-2023-01-04-alle-12.17.36-resized.jpg] (note the dynamic IP address network) then I declare the subnet to which all clients should be given access (I previously named this subnet LAN B) Then, on specific USER PERMISSION (OPENVPN ACCESS SERVER) I set: [image: 1672831332682-schermata-2023-01-04-alle-12.21.28-resized.png] So that the user I'm connecting from will be capable of reaching both my client side LANS (the pfsense's ones) CLIENT SIDE (pfsense) No tunnel ip has been declared (because it is dynamically provided by the server) [image: 1672831462177-schermata-2023-01-04-alle-12.23.45-resized.png] The remote LAN I want to reach has instead been declared (192.168.1.0/24 - SERVER SIDE LAN) NO GATEWAY NOR STATIC ROUTE HAS BEEN MANUALLY SET; THEY GOT CREATED BY OPENVPN CLIENT ITSELF [image: 1672831589134-schermata-2023-01-04-alle-12.26.02-resized.png] Everything's working now: I can ping the external LAN (server side - 192.168.1.0/24) from both my pfsense LANs (192.168.3.0/24 and 192.168.4.0/24). Thank you once again!

@viragomann That was one of the first things I did when I rebuilt the network (static assignment). It wasnt DHCP, I just assigned it from a new block of addresses I'd reserved for a few devices. It just didn't remotely occur to me there would be dependencies on that IP within that client box. That just goes back to my lack of familiarity with the internals of the OpenVPN server box he is using. Hey, at least I learned something.....

I think it's got to be some sort of asymmetric issue. What would I look at to investigate that? I think it's not a pfsense firewall being cleared during testing because a) I'm not clearing it and I'm theonly admin and b) if I try the test a few hours later I get the same results. Just before retrying the test later I confirm the openVPN has no sessions on it. That being said maybe I should try clearing the sessions of both the LAN and WAN? I do have my clients when testing on my LAN just before disconnecting and joining the openVPN over the WAN.

@visseroth said in OpenVPN no traversing: @jknott I agree though I'm not quite sure how to correct that problem. If I check the routes on my firewall for 192.168.1 nothing comes up Your network knows how to reach the other end of the VPN, as it's network is directly connected to your firewall. You have to create a route for the LAN at the other end via the VPN. Then, any device on your LAN will be able to get to the other LAN, with the default route pointing to your firewall and your firewall will know how to get to the LAN at the other end of the VPN.

@jsnl said in OpenVPN dies and wont restart when my main internet temporarily goes down: I'm unsure if my issue is related and so I've opened a new topic, but I have this happen when my remote (not my server) internet is unstable. In my case I think it has something to do with exceeding the maxclients value. Is your maxclients value set low, or at the default number? This is the thread I just opened with my logs attached. I dont have an option for maxclients in this config. I think because you're having problems with PFSense as an OpenVPN server and im having a problem with PFSener as an OpenVPN client

@jsnl said in OpenVPN quits on unstable client connection: Inactive: 300 I'm using the default settings : [image: 1672324428319-3f56ae85-9af4-462e-ad91-f6c4f5ac9320-image.png] Did you solved the huge clock time difference between the client and the server ? 1 minute is far to much. @gertjan said in OpenVPN quits on unstable client connection: When you see a packet coming in on "13:03:26" an the packet states it was send at "13:02:24" then the message (may be a replay) makes sense.

@dajones13 Thank you for your response. I ended up figuring out about the push notification. However, I did not know about the phone call option which is great to know. I also had the encryption set to PAP instead of MSCHAP which I don't think was the issue but I changed it prior to the VPN working so it could have been a factor. Thanks a lot!

@djdmx Good to hear!! Sorry I haven't answered any of your posts, just getting over the flu. But you didn't need my help anyway!

@albinali ok so i figured it out, when i inspected the route table i noticed it was messed up (probably because i was playing around too much), i rebooted the PFsense device and i can connect now.

@jarhead problem solved, I was missing some static routes on both the routers... I opened a new topic here since I now have different issues with rules and interface. Thank you

@solarhacker I would reach out to whoever is the OVPN host and see what they say at this point... or wait for someone else to see this thread suggests. If you're the host check the remote-side logs.

@rm17 "We" all want this but it is not gonna happen. Again, there is no policy routing for the resolver in pfSense.

@jarhead Yeah it's definitely a problem with NAT, I tried logging into the router to change it and I couldn't even change the wifi password..