OPNsense Forum
Archive => 17.7 Legacy Series => Topic started by: PotatoCarl on August 03, 2017, 03:24:33 pm
-
Hi,
I yesterday upgraded from my 17.1.11 to 17.7, which immediately broke my IPSEC VPN to my FritBox. I now get only timeouts (on the Fritzbox) while the OPNSenstartet with timeout (once) and then keeps retransmitting.
I thing there is a major issue with IPSEC in the upgrade.
Please, anyone help to fix this again?
Thank you.
PS: I did not change any setting on neither the FritzBox nor the OPNSense and rebootet both devices several times.
-
Can you try this?
# opnsense-patch 511cdd471
Rerun the filter reload under Firewall: Diagnostics: Filter reload.
Cheers,
Franco
--
https://github.com/opnsense/core/commit/511cdd471
-
Wow, cool. Works.
Thanks a lot!
But, well, why does it not do it automatically? Do I have to redo this every time I boot? Because I bootet the OPNSense a few times.
Just opened another one because of a broken Squid...
-
The code in question caused a reconfigure issue where the firewall rules were not correctly written sometimes. We need to safely rewrite this another way. This was very subtle gateway magic that for years prevented multi-wan for services running on the box (like openvpn or squid).
Cheers,
Franco
-
Ooookay, so that means that multi-wan for openVPN and squid is now possible?
I was actually running quid on a multi-wan setup now for some time, which worked fine until, well, I updated yesterday. Now my transparent proxy seems to be broken.
I have actually no idea what the problem is, as I get network timeouts only. I can turn it off, but this is not really what I want.
I can't find any reasons actually why it goes wrong. Maybe it is because the NAT forward is to the 127.0.0.1 address but Squid listens on LAN only? I cannot enter localhost as network...
I opened another topic for that, I just wonder if it may be related.
-
It doesn't mean Multi-WAN + Proxy in the same setup, it means Multi-WAN *for* the Proxy's requests themselves, hidden from the user. As far as I remember, this never really worked.
The proxy issue happened *after* you applied the patch? It could be a side effect now that loopback is also routed to itself, which doesn't seem right. It clearly wasn't this way before, but the code was removed before we moved loopback gateways into the rule generation code so that may overlap.
Log into SSH / console, edit /tmp/rules.debug, delete the two lines starting with "pass out log route-to ( lo0", save the file, and then type:
# pfctl -f /tmp/rules.debug
to reload the filter and try again.
Cheers,
Franco
-
Hi
thanks again for the quick reply. I believe it happened after I reloaded the filters. But now you're asking I am not 100% sure anymore, it definetly worked before the update.
I try to remake the NAT rule from the Proxy Interface, but it did not have any effect. If I turn off NAT and the firewall rule that corresponds, then enable the direct passthrough it works (of course) again, but not via proxy. But, and this is kind of strange, the filter seems to work... So maybe squid is working? How can I find out if it does? Because the blacklisted pages get a timeout, while the others do not show ads (this is where I use the filters).
Coming back to your proposal: I don't have those lines in this file.
I have such as
pass out log quick on em2 proto udp from {(self)} port {67} to {any} port {68} label "allow access to DHCP server"
and looking for lo0 (grep lo0 /tm/rules.debug):
loopback = "{ lo0 }"
pass in log quick on lo0 inet6 from {any} to {any} label "Pass all loopback IPv6"
#block in quick on lo0 from {<bogons>} to {any} label "block bogon IPv4 networks from loopback"
#block in quick on lo0 from {<bogonsv6>} to {any} label "block bogon IPv6 networks from loopback"
#block in quick on lo0 from {10.0.0.0/8,127.0.0.0/8,100.64.0.0/10,172.16.0.0/12,192.168.0.0/16,fc00::/7} to {any} label "Block private networks from loopback"
pass in log quick on lo0 from {any} to {any} label "pass loopback"
Would any of those correspond to what you mentioned?
Regards
-
If you have patch 511cdd471 applied, there should be these lines. It seems you removed the patch again?
-
Okay, maybe I misunderstood there something.
You mentioned the patch, so I did go to firewall->diagnostics->reload filter.
I did not install anything, but from that moment on IPSEC was immediately working again.
Should I have installed something else?
When I do this again, (i.e. reload filter), i still get the same output of the grep on that file. So no, those lines are not present.
Did I do something wrong?
-
No, just a miscommunication then, sorry! :)
So that would indicate your IPsec cannot start during a reboot, but once you reload the filter, it will?
As far as the proxy... it could just be a hiccup in the way it was set up that happened to work before, but now doesn't due to loosely related rule generation work.
I set up a transparent proxy with a NAT rule for port 80 and went to http://test-ipv6.com/, it said:
Your IPv4 address on the public Internet appears to be xx.xx.xx.xxx
Proxied, Via: 1.1 localhost (squid/3.5.26)
Your traffic gets redirected somewhere else, that's the most likely answer. It only does that if it was told to do it.
Have you set a default gateway?
Can you install plugins?
Is squid running?
Do you have gateway firewall rules?
Do you expect the proxy traffic to go through a VPN tunnel?
Cheers,
Franco
-
Just tried to reboot the OPNSense and see what happens...
Okay, finding 1:
Transparent Proxy works again (-> NAT and Firewall rule reactivated of course).
Finding 2:
IPSec is not working.
OpenVPN works (yes, we use both).
Now: Reload Firefall rules.
Finding 1:
Squid ist still working as transparent Proxy (WTF???)
Finding 2:
IPSec is not...
Regarding your questions:
Default gateway: No. I use a Multi-WAN setup with a WAN Group, Port 1 (VPN Port) is Tier 1, other is Tier 2
Install plugins: Yes, no problem
Squid running: Yes
Gateway Firewall rules: Not sure what you mean, yes, there are a number of rules
Proxy/VPN: No, should go directly to the net.
Now I am more confused than before...
-
Time is sometimes the key... IPSEC came up again.
So now it seems to work completely again. I am not sure what in the end was doing it - multiple reboots, filter reload, whatever... so, it works, I am happy, but confused.
Thank you for your help.
-
Hey,
I've got the same problem.
I configured a site-to-site tunnel between my opnsense and a FritzBox in a remote location.
Before the upgrade to 17.7 everything was working fine, after the upgrade phase 1 seems to come up, but the phase 2 between my and the remote not does not come up.
I already tried reloading the firewall rules before and after applying the suggested patch but I had no luck.
Any further suggestions?
Greetings,
Felix
-
Hi,
Unfortunately the "Solved" is not correct. I cannot get a stable connection. Sometimes it connectes, and after some minutes it breaks again.
I am very sure that my internet connection is not a problem (although OPNSense tends sometimes to consider the main interface as offline, which is definetly not the case).
I could see yesterday nicely that I got connected for about 20 minutes, and the the conneciton broke down. As I could easily check emails (direct port) but could not connect via IPSSec (OpenVPN worked) I believe there must be some problem with IPSec since the upgrade.
I reinstalled the strongswan package but this did not have any effect.
More ideas?
-
Update: Meanwhile there is no connection possible anymore. I only get "timeout".
Here is the log:
Aug 8 12:22:32 charon: 08[JOB] deleting half open IKE_SA with a.a.a.a after timeout
Aug 8 12:22:26 charon: 08[NET] sending packet: from b.b.b.b[500] to a.a.a.a[500] (388 bytes)
Aug 8 12:22:26 charon: 08[IKE] sending retransmit 3 of response message ID 0, seq 1
Aug 8 12:22:16 charon: 08[NET] sending packet: from b.b.b.b[500] to a.a.a.a[500] (388 bytes)
Aug 8 12:22:16 charon: 08[IKE] received retransmit of request with ID 0, retransmitting response
Aug 8 12:22:16 charon: 08[NET] received packet: from a.a.a.a[500] to b.b.b.b[500] (660 bytes)
Aug 8 12:22:13 charon: 08[NET] sending packet: from b.b.b.b[500] to a.a.a.a[500] (388 bytes)
Aug 8 12:22:13 charon: 08[IKE] sending retransmit 2 of response message ID 0, seq 1
Aug 8 12:22:08 charon: 08[NET] sending packet: from b.b.b.b[500] to a.a.a.a[500] (388 bytes)
Aug 8 12:22:08 charon: 08[IKE] received retransmit of request with ID 0, retransmitting response
Aug 8 12:22:08 charon: 08[NET] received packet: from a.a.a.a[500] to b.b.b.b[500] (660 bytes)
Aug 8 12:22:06 charon: 08[NET] sending packet: from b.b.b.b[500] to a.a.a.a[500] (388 bytes)
Aug 8 12:22:06 charon: 08[IKE] sending retransmit 1 of response message ID 0, seq 1
Aug 8 12:22:04 charon: 08[NET] sending packet: from b.b.b.b[500] to a.a.a.a[500] (388 bytes)
Aug 8 12:22:04 charon: 08[IKE] received retransmit of request with ID 0, retransmitting response
Aug 8 12:22:04 charon: 08[NET] received packet: from a.a.a.a[500] to b.b.b.b[500] (660 bytes)
Aug 8 12:22:02 charon: 08[NET] sending packet: from b.b.b.b[500] to a.a.a.a[500] (388 bytes)
Aug 8 12:22:02 charon: 08[ENC] generating AGGRESSIVE response 0 [ SA KE No ID V V V NAT-D NAT-D HASH ]
Aug 8 12:22:02 charon: 08[CFG] selected peer config "con3"
Aug 8 12:22:02 charon: 08[CFG] looking for pre-shared key peer configs matching
Maybe that's helpful.
Cheers
-
My log looks the same, so I think we suffer from the same bug.