Messages

Anyone? Any suggestions? May be more logs to look into? Please...  :(

Hello!
I've got 2 Opnsense boxes running in different cities, connected with site-to-site IPSec VPN.
On site1 I've got 2 WANs from different ISPs, lets say, isp1 (100mbps, primary) and isp2 (50mbps, secondary), failover. On site2 I've got 1 WAN, same isp2 (100mbps).
When I tried site1:isp1<->site2:isp2 connection - that was not very good, ping rtt inside IPSce tunnel is about 85 ms. So, I use site1:isp2<->site2:isp2 connection and get 25 ms rtt - not bad.
Also, on site1 Opnsensebox I have l2tp server for the remote windows clients to login (I prefer solutions, which don't need third-party software, that is why L2TP, not openvpn).
And here comes the problem. When l2tp client disconnects, strongswan resets the tunnel to site1:isp1<->site2:isp2.
This is what I see in ipsec.log at the moment, when the tunnel site1:isp2<->site2:isp2 is up and l2tp client disconnects:

Code Select Expand


Sep  4 08:35:27 pnz-gw charon: 02[KNL] interface ng0 appeared
Sep  4 08:35:27 pnz-gw charon: 02[IKE] <con2|15> old path is not available anymore, try to find another
Sep  4 08:35:27 pnz-gw charon: 02[IKE] <con2|15> looking for a route to $site2ip ...
Sep  4 08:35:27 pnz-gw charon: 02[IKE] <con2|15> sending address list update using MOBIKE, implicitly requesting an address change
Sep  4 08:35:27 pnz-gw charon: 02[ENC] <con2|15> generating INFORMATIONAL request 4 [ ]
Sep  4 08:35:27 pnz-gw charon: 02[IKE] <con2|15> checking path $site1ip1[4500] - $site2ip[4500]
Sep  4 08:35:27 pnz-gw charon: 02[NET] <con2|15> sending packet: from $site1ip1[4500] to $site2ip[4500] (96 bytes)
Sep  4 08:35:27 pnz-gw charon: 13[NET] <con2|15> received packet: from $site2ip[4500] to $site1ip1[4500] (96 bytes)
Sep  4 08:35:27 pnz-gw charon: 13[ENC] <con2|15> parsed INFORMATIONAL response 4 [ ]
Sep  4 08:35:27 pnz-gw charon: 13[ENC] <con2|15> generating INFORMATIONAL request 5 [ N(ADD_4_ADDR) N(ADD_6_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(AD
Sep  4 08:35:27 pnz-gw charon: 13[NET] <con2|15> sending packet: from $site1ip1[4500] to $site2ip[4500] (192 bytes)
Sep  4 08:35:28 pnz-gw charon: 13[NET] <con2|15> received packet: from $site2ip[4500] to $site1ip1[4500] (96 bytes)
Sep  4 08:35:28 pnz-gw charon: 13[ENC] <con2|15> parsed INFORMATIONAL response 5 [ ]

So I get not very good speed inside tunnel until I manually restart strongswan daemons.
May be someone can help me with that? Thanks in advance!
P.S. This behavior was on 18.1.<any> and now on latest 18.7.1 is the same

ive been running Lagg on both our wan side and lan side of our OpnSense boxes...

Which NICs do you use?

Today the master VM cannot boot properly. It segfaults in about 1 min after booting to shell. Could get it running only after detaching passthrough NICs.

Yesturday I caught couple of kernel panics while trying to do something with LAGG interface. lagg0 was assigned to LAN with IP address 192.168.0.2 (I was running another VM with OPNsense as default router for my net). And I created all Vlans I wanted. So, I shut down the reserve VM and tried to change IP address on LAN interface on master VM to 192.168.0.1 - got segfault. Then, after reboot, I tried to change assignment of LAN interface from lagg0 to vmx0 - and got second segfault. Submitted another bug report from GUI.

Damn, it had gone away after I re-created the LAGG interface!
:-\

Sort of necroposting, but anyway - I have very similiar trouble.
I've got an OPNsense virtual appliance on VMWare. It had 3 virtual NICs (vmxnet3) and on LAN interface I've got some VLANs and everything worked good until...
So, I wanted to aggregate 2 NICs for LAN. For this I installed new physical NIC into the server (HP Proliant DL580 Gen8) - HP 361T (based on Intel i350 chip) with 2 1GBe ports. Then I turned on passthrough for it on VMWare host and added to OPNSense guest VM. After that, I configured LACP LAGG interface (with igb0 and igb1 members) and it was working well without 802.1q VLANs. Naturally, my next step was to add VLANs on that new interface, and here I got the kernel panic, when the parent interface is LAGG. And it happens every time I try. I submitted the issue report, but decided to post it here also.
Needless to say, that all hardware features are turned off (CRC, TSO, LRO, Vlan filtering).
Also, adding Vlans on igb0 or igb1 without aggregation works well.
May be there is something else, I could try to do?

Для этого есть плагин os-web-proxy-sso

На сколько я понял в процессе экспериментов, интерфейс LAN, назначенный из консоли (НЕ OPT[X]!) надо юзать именно для локальной сети, т.к. под него создаются правила в фаере и все такое. Т.е. синхронизацию между фаерволами лучше пустить через OPT2, а LAN - оставить именно для клиентов.
P.S. Я пробовал создавать LAGG из 2 интерфейсов, при этом LAN был назначен на другой интерфейс, который существовал изначально (и на нем был IP 192.168.0.1, являющийся шлюзом по умолчанию для всей сети). Потом я, не меняя назначений в Interfaces -> Assignments, поставил на LAGG адрес 192.168.0.1, а на LAN 192.168.0.2. В результате получил совершенно непонятные глюки на ровном месте, не смотря на разрешающее правило в фаере на новый интерфейс.