1
18.7 Legacy Series / Re: Inexpectable VPN behavior
« on: September 06, 2018, 07:50:03 am »
Anyone? Any suggestions? May be more logs to look into? Please... 
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1]
2
18.7 Legacy Series / Inexpectable VPN behavior
« on: September 04, 2018, 10:34:52 am »
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:
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
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]
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
3
18.1 Legacy Series / Re: Vlan over LAGG with LACP- release 18.1 on A10 quad core
« on: May 31, 2018, 08:46:10 am »ive been running Lagg on both our wan side and lan side of our OpnSense boxes...Which NICs do you use?
4
18.1 Legacy Series / Re: Vlan over LAGG with LACP- release 18.1 on A10 quad core
« on: May 31, 2018, 08:30:52 am »
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.
5
18.1 Legacy Series / Re: Vlan over LAGG with LACP- release 18.1 on A10 quad core
« on: May 31, 2018, 07:52:46 am »
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.
6
18.1 Legacy Series / Re: Vlan over LAGG with LACP- release 18.1 on A10 quad core
« on: May 30, 2018, 10:01:15 am »
Damn, it had gone away after I re-created the LAGG interface!
7
18.1 Legacy Series / Re: Vlan over LAGG with LACP- release 18.1 on A10 quad core
« on: May 30, 2018, 09:36:22 am »
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?
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?
8
Russian - Русский / Re: Авторизация на прокси сервере
« on: May 30, 2018, 08:55:40 am »
Для этого есть плагин os-web-proxy-sso
9
Russian - Русский / Re: Прошу помощи с настройкой intel350t4v2
« on: May 30, 2018, 08:46:56 am »
На сколько я понял в процессе экспериментов, интерфейс 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. В результате получил совершенно непонятные глюки на ровном месте, не смотря на разрешающее правило в фаере на новый интерфейс.
P.S. Я пробовал создавать LAGG из 2 интерфейсов, при этом LAN был назначен на другой интерфейс, который существовал изначально (и на нем был IP 192.168.0.1, являющийся шлюзом по умолчанию для всей сети). Потом я, не меняя назначений в Interfaces -> Assignments, поставил на LAGG адрес 192.168.0.1, а на LAN 192.168.0.2. В результате получил совершенно непонятные глюки на ровном месте, не смотря на разрешающее правило в фаере на новый интерфейс.
Pages: [1]