Messages

1

19.1 Legacy Series / Re: Packets from LAN to OpenVPN road warrior client get routed to WAN

« on: March 14, 2019, 09:46:48 am »

Are hosts on the lan windows based?

On the LAN we have Windows, Mac and Linux. The traceroute was done from both a Mac and Linux host with the same result.

Why you trace to 10.10.12.3 and not to 10.10.12.2?
What about 10.10.12.1, where you define it?

We have multiple client connecting through that VPN, 10.10.12.1 is the IP of the router's vpn interface and 10.10.12.2, 10.10.12.3 etc... are each client. What defines that is in VPN > Servers> IPv4 Tunnel Network that is set to 10.10.12.0/24 (and we are in topology mode). As for why I included a traceroute to 10.10.12.3 instead of 10.10.12.2, well, it is because I didn't pay enough attention when I wrote the message :-) (I corrected it now).

Thanks!

2

19.1 Legacy Series / Packets from LAN to OpenVPN road warrior client get routed to WAN

« on: March 13, 2019, 08:04:51 pm »

Hello,

This thing has been driving me crazy for a while now. I have an OPNSense 19.1.4 router with an OpenVPN road warrior setup. It works perfectly fine and the client connecting through VPN can connect to any host on the LAN (which also means that replies from those hosts get routed back correctly). However trying to connect from a host on the LAN to the address of the OpenVPN client always fail.

The setup looks like this (there are also two WAN interfaces to the internet not shown here):
VPN Client 10.10.12.2 <-> |10.10.12.1 Router 10.10.10.10| <-> 10.10.10.40 LAN host

Traceroute from VPN client to LAN host is correct
traceroute to 10.10.10.40 (10.10.10.40), 64 hops max, 52 byte packets
 1  10.10.12.1 (10.10.12.1)  15.706 ms  14.337 ms  18.585 ms
 2  10.10.10.40 (10.10.10.40)  22.600 ms  18.737 ms  16.566 ms

While trace route from LAN host to VPN client is wrongly routed to the internet
traceroute to 10.10.12.2 (10.10.12.2), 30 hops max, 60 byte packets
 1  85.195.x.x (85.195.x.x)  0.825 ms  0.668 ms  0.685 ms
 2  82.197.x.x (82.197.x.x)  0.784 ms  0.777 ms  0.869 ms

Routing tables in OPNSense seem correct:
ipv4   10.10.12.0/24   10.10.12.2   UGS   576   1500   ovpns1       
ipv4   10.10.12.1   link#9   UHS   0   16384   lo0       
ipv4   10.10.12.2   link#9   UH   1200   1500   ovpns1

And catching packets at every interface confirms what traceroute shows (nothing goes through at the OpenVPN interface of the server when coming from LAN to VPN, but packets are logged when going from VPN to LAN).

My NAT outbound rules are auto-generated as follows:
WAN   LAN networks, 127.0.0.0/8, 10.10.12.0/24   *   *   500   WAN   *   YES   Auto created rule for ISAKMP
WAN   LAN networks, 127.0.0.0/8, 10.10.12.0/24   *   *   *   WAN   *   NO   Auto created rule
WAN2   LAN networks, 127.0.0.0/8, 10.10.12.0/24   *   *   500   WAN2   *   YES   Auto created rule for ISAKMP
WAN2   LAN networks, 127.0.0.0/8, 10.10.12.0/24   *   *   *   WAN2   *   NO   Auto created rule

If anybody has any idea for troubleshooting this, it would be much appreciated!

Many thanks

3

17.1 Legacy Series / Re: Problem with Let's Encrypt plugin

« on: April 28, 2017, 03:25:04 pm »

Thanks whitenosethunderpants, this said, it is quite inelegant, it will reset the GUI on you depending on what you are doing so a real fix is definitely needed. Unfortunately I don't have enough knowledge to create the elegant solution.

4

17.1 Legacy Series / Re: Problem with Let's Encrypt plugin

« on: April 26, 2017, 12:36:30 am »

(Oh, and while we're at it, certhelper.php also crashes on line 123 when a certificate has been removed in Services > Let's Encrypt > Certificates )

[26-Apr-2017 00:28:08 Europe/Zurich] PHP Warning:  cert_action_validator(): Node no longer exists in /usr/local/opnsense/scripts/OPNsense/AcmeClient/certhelper.php on line 123

5

17.1 Legacy Series / Re: Problem with Let's Encrypt plugin

« on: April 26, 2017, 12:14:37 am »

I just updated OPNsense and tested the fix, unfortunately it looks like variable $backend is null so the script crashes with the following stack trace (I've also submitted it through the reporter). I've replaced line 727 "$response = $backend->configdRun('filter reload');" by "mwexec('/usr/local/etc/rc.reload_all');" and it seems to be working as a temporary workaround.
Best,

[25-Apr-2017 23:55:26 Europe/Zurich] PHP Fatal error:  Uncaught Error: Call to a member function configdRun() on null in /usr/local/opnsense/scripts/OPNsense/AcmeClient/certhelper.php:727
Stack trace:
#0 /usr/local/opnsense/scripts/OPNsense/AcmeClient/certhelper.php(214): run_acme_validation(Object(SimpleXMLElement), Object(OPNsense\Base\FieldTypes\ContainerField), Object(OPNsense\Base\FieldTypes\ContainerField))
#1 /usr/local/opnsense/scripts/OPNsense/AcmeClient/certhelper.php(85): cert_action_validator('58f7e39960c846....')
#2 {main}
  thrown in /usr/local/opnsense/scripts/OPNsense/AcmeClient/certhelper.php on line 727

6

17.1 Legacy Series / Problem with Let's Encrypt plugin

« on: April 22, 2017, 08:38:56 pm »

Hello,
I am trying to use the Let's encrypt plugin version 1.4, in HTTP-01 mode with the OPNsense port forward option, the plugin works fine as I can see it reach "Installing full chain to:/var/etc/acme-client/certs/..." at the end of the log. However, it leaves my router in a mode where packets in and out are blocked, and there seems to be way to few rules in pf (if I list them in the shell, GUI seems normal). Reloading config using /usr/local/etc/rc.reload_all seems to fix the problem so my guess is that the plugin doesn't cleanup after itself and restore the original NAT and/or rules after running the acme protocol and installing the certificate.
The problem is reproducible 100% of the time so please let me know if you need me to run more tests. As a workaround, I would have run /usr/local/etc/rc.reload_all as a custom restart action, but it looks like this option was removed in version 1.4 of the plugin :-( .
Thanks in advance,