OPNsense Forum

Archive => 17.7 Legacy Series => Topic started by: Juergen on October 07, 2017, 11:44:22 pm

Title: pptp reconnect needs filter reload
Post by: Juergen on October 07, 2017, 11:44:22 pm
Hello!

I am running OPNsense 17.7.5-amd64 on vmware ESXi 6.5.
My WAN-connection is via PPTP on an ADSL-modem.

Problem:
Every time when the WAN-connection goes down (eg. modem reboot or provider resets the line) pptp can not reconnect to the modem. The modem sits on a separate interface(em1) and I can no longer ping it after the pptp comes up.
The Point-to-Point Log shows connection attempts but gets no answer from the modem. To reconnect I have to restart pf via the dashboard.
This problem is present since at least 16.7 and then my solution was to do a filter reload via cron-jobs and ifup/down, but filter reload is gone and I suspect this behavior is not expected.
Of course I checked my firewall rules but i am unable to spot an error.

Please can anyone help me with that?

Thank you very much!
Title: Re: pptp reconnect needs filter reload
Post by: bartjsmit on October 08, 2017, 12:10:58 am
I guess you mean PPPoE? PPTP is a rather discredited VPN protocol.

Which vNIC type do you use for the WAN interface? Do you use a standard vSwitch or a distributed one? Do you have the VMware tools plugin installed in OPNsense?

Bart...
Title: Re: pptp reconnect needs filter reload
Post by: Juergen on October 08, 2017, 01:31:25 pm
Hi Bart,

I really mean PPTP. For some obscure historical reason nearly all ADSL-Providers in Austria use PPTP. Basically you create a V VPN to your modem which connects to your provider. Modems in Austria are provided by the internet-provider and not exchangeable....

I am using E1000 (emulated Intel card) for the WAN and LAN Ports and they are connected to a vSwitch. The VMware tools are installed.

There are no other problems beside the re-/connection problem. I am using NAT from the LAN to the WAN and some port forwarding.

My main problem ist that if the connection goes down and I am not on site I have no way of reestablishing the connection, so for a start some code to do a filter reload or pf restart via cli would help a lot. But I am willing to debug this fully.

Thanks!
 
Title: Re: pptp reconnect needs filter reload
Post by: bartjsmit on October 08, 2017, 06:38:01 pm
Ouch, that's nasty!

Unless you can figure out a trigger, I would say a cron job is your best bet. Check connectivity to an external host every 5 minutes and reset pf if no response.

You can try vmxnet3 but I have a feeling it won't make much difference.

Bart...
Title: Re: pptp reconnect needs filter reload
Post by: franco on October 09, 2017, 10:04:13 am
Hi Juergen,

16.7 is an odd place for this to have started happening, but it might narrow down why this is the case.

The biggest question is: what actions are required to reestablish connectivity? Can you share the system logs of when it connects file (PPP log as well) and when it gets stuck?

Also, do you have gateway monitoring set up? It might help with a reloading...

FWIW, I'm guessing the linkup event gets stuck, maybe even the PPP daemon doing the connecting, hanging, preventing the interface from reloading correctly. The logs should reveal that.


Cheers,
Franco
Title: Re: pptp reconnect needs filter reload
Post by: Juergen on October 14, 2017, 10:41:53 pm
Hi Franco,

sorry for the delay, I did some more testing. 16.7 was an estimate, actually I have the Problem since my first install of OPNsense which was 16.1 (I found the install image on my ESXi).
To help debugging I did a fresh install of 17.7 followed by update to 17.7.5 without touching the firewall-rules. I just created the pptp connection and the problem is the same.
I can share the logs but first let me tell what the tests showed:
LAN is em0 (192.168.10.0/24)
ModemNet is em1 (10.0.0.140/24)
WAN is pptp0 (adddress *.*.*.* via pptp)
The modem sits on 10.0.0.138 and after restart or filter reload I can ping it from the firewall.
After pptp is established I can no longer ping 10.0.0.138 even when all packet filtering is disabled.
The routes are like this:
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            217.25.113.2       UGS       pptp0
10.0.0.0/24        link#2             U           em1
10.0.0.140         link#2             UHS         lo0
10.0.3.0/24        10.0.3.2           UGS      ovpns1
10.0.3.1           link#8             UHS         lo0
10.0.3.2           link#8             UH       ovpns1
*.*.*.*      link#9             UHS         lo0
127.0.0.1          link#5             UH          lo0
192.168.10.0/24    link#1             U           em0
192.168.10.1       link#1             UHS         lo0
217.25.113.2       link#9             UH        pptp0

When I ping 10.0.0.138 from the firewall I get nothing back and pfTop-State shows:
icmp      Out *.*.*.*:11868                  10.0.0.138:11868                               0:0            00:01:56  00:00:10      229    19236      165   71 10.0.0.138:13083   

For me this looks wrong, as the modem can not know where *.*.*.* is, so there can be no answer.
But even if I specify the Interfave (ping -S 10.0.0.140 10.0.0.138) the output of pftop shows x.x.x.x as SRC.
BTW the tunnel shows up as:
gre       Out 10.0.0.140:0                                  10.0.0.138:0                                     MULTIPLE:MULTIPLE     04:09:29  00:01:00   501361  419039K                                 

which looks OK.

hmmm

Thanks,
Juergen