Thanks Manuel !

This was just what I was looking for.
At least, when tried from the firewall, it worked (127.0.0.1 and LAN gw answered after the change). I will visit the customer and double check it from the workstation but pretty sure that this was the solution.

Appreciate Your help.

/ best regards, pete

@kiokoman thx your right

UP

by default only the first 100 routes are displayed in diagnostic routes. Solved.

@ilGino said in IPsec tunnel pfSense - Fortigate disconnects and reconnects:

invalid HASH_V1 payload length, decryption failed

It is some mismatch on the ID or Phase1 configuration
"My Identifier" and "Peer Identifier" fields in the Phase 1 Proposal for example

also i would check IKE_SA lifetime if they are the same
you need to compare it with the fortigate

PHEW ! Well that was emotional... ok so all working now. Basically I had to stop the IPSEC service (and I mean STOP not restart)… wait a few seconds and then start it again and now it all connects just fine....

Thanks all for your kind replies appreciated

Bump and some additional info:
With that line removed, we initially thought we had gotten rid of the problem, but it looks like we only added delay. After about 2 weeks, the IPSec tunnels entered the same weird state where they are up and traffic going out can be seen, but dpinger (or a manual ping) seems to never reach the remote end. Hard to tell if the exact timing is reproducible, but it will happen again eventually after a few days/weeks. (we've seen it happen twice since i initially posted here).
Rebooting seems to be the only way to fix this. Restarting ipsec service didn't do anything, neither did disconnecting the tunnels via webinterface and reconnecting.

Our resort for now was to move the AWS Site-to-Site tunnels off to an EdgeRouter, as we only started to encounter the issues once they were added. Worker fine before with only pfsense<->pfsense tunnels. I'll continue to monitor the situation, and am waiting for the 2.4.5 release to become available. Hopefully the various bugfixes will in the end resolve the problem.
I'll also soon have the opportunity to make another, almost identical setup using two MB-4220T pfsense appliances (https://store.netgate.com/MBT-4220-system.aspx) instead of SG-3100s.

Finally, I solved making a VPN IPsec site-to-site between the networks using a pair of firewalls.

to route all the traffic though IPsec tunnel please follow the below configuration.

you need firewall Aliases.
cc7dc5c1-f3f5-4e83-b444-5aa06b44d60a-image.png
30ea59c5-81e8-4f77-9ee5-213982ae04bc-image.png

you need virtual IP for DNS routing could be any

bb864545-61b8-4176-a3a5-6875ebf07d2b-image.png

a02e11a5-0657-4322-b622-a5f6a56ee72f-image.png

Set the above virtual ip as DNS for vpn clients.

b5851bc7-ecc7-4417-a518-8488912b53ff-image.png

hope this should work for you.

Thanks
Daman

Hi,

Yes it is possible to setup Routed IPsec over VTI in Pfsense 2.4.4-p1+ alongside FRR BGP. Generally speaking the steps are correct in https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/ipsec-routed.html. Here's some example config to get others going though.

In Azure:

Azure Example VNET Prefix(s): 192.168.0/16, 172.28.80.0/27
Azure GatewaySubnet Prefix: 172.28.80.0/27

Azure Local Network Gateway:

On Premise Remote IP: 1.1.1.1
Address Space: 172.28.80.1/32
Configure BGP: x
ASN: On-Premise ASN (Eg. 65512)
BGP Peer Address: 172.28.80.33

Azure Virtual Network Gateway:

SKU: VpnGwx
Configure BGP: x
ASN: A different ASN for Azure side (ASN 65515 is the default)
BGP Peer IP Address: 172.28.80.5 (Default itll allocate one for you in the GatewaySubnet)

Virtual Network Gateway Connection:

Youll need to define a matching IKEV2 policy. I went with:

dh_group = "ECP256" ike_encryption = "DES3" ike_integrity = "SHA256" ipsec_encryption = "DES3" ipsec_integrity = "SHA256" pfs_group = "ECP256"

It shouldn't matter too much so long as they match at both ends.

Set a suitable pre-shared key.
Finally ensure the connections has BGP enabled.

In Pfsense:

On the P1:
Define a matching policy that you set on Azure
Pre-shared key
Public ip you allocated and then assigned to the Virtual Network Gateway (Must be a dyanmic PIP btw)

On the P2:
Local Network Address: 172.28.80.33/32
Remote Network Address: 172.28.80.5/27

FRR BGP:

I wont write this out as theres nothing special here. Set your local and remote ASNs correctly. understand what your advertising and what you should be receiving etc...

The gotchas

Only recent revisions of Pfsense 2.4.4 correctly append 0.0.0.0/0 to right and left side of the tunnels in strongswan. This is important here as we aren't defining policy selectors and need this wildcard so we can use BGP dyanmically. This was likely the issue Richard was encountering I'd guess.

Note how my VPN range for local network address is outside of the GatewaySubnet range. This is intentional. Basically Azure wants to own the range you set for GatewaySubnet so you cant use it on premise despite what the Pfsense guide says. Additionally Azure won't peer with a BGP Peering IP that's part of this range. It must be outside of its routeable ranges. So you could also set the BGP peering IP to another entirely unrelated ip on the box eg. 10.0.0.1 (other than the WAN ip you connect Azure too on the P1).

As the Azure doc says the minimum address space, and in fact only address space, you need on the LNG is the ip of the BGP peer on Pfsense. Otherwise youll end up with a connection up but nothing being sent down it from Azure.

Normal Ipsec rules apply. If your P1 doesnt connect, you've probably not matched either the IKEv policy or the PSK at both ends. Diagnose that before you go any further. If the P2 doesn't connect, check your addresses and the policy on the P2 etc..

Fun fact you can ping the Azure VGWs by default. So if you cant ping it across the tunnel fix that before you fiddle with BGP.

FRR and Strongswan have a pretty terrible bug https://redmine.pfsense.org/issues/9668 that means every time your connection goes down (say due to Azure maintenance) or you update ipsec config on even unrelated connections it messes up the BGP -> Kernel route table and you end up with a broken routing table. Be warned and be nice to Netgate and FRR so they fix it ;)

Good luck and have fun!

You would need one of two things:

Setup a Dynamic DNS hostname using the same failover group as the IPsec local interface. Use a single tunnel with the other side using that Dynamic DNS address for the peer. Do the same on the remote end. This works, but can be slow to respond. Because of how DNS TTLs and timing it could be several minutes before the tunnel recovers.

-OR-

Use VTI mode, keep two tunnels up at all times, and use a dynamic routing protocol to decide which tunnel will have traffic routed across. This fails over much faster, but is a bit more involved to setup.

Both of those have been discussed in numerous threads here on the forum, search around a bit and you're certain to find enough information to guide you either way.

There is a chance this may behave better on 2.5.0 since it's been converted to the new swanctl format for IPsec config. Though since it defers to RADIUS it still might not keep records in that location for that type of setup.

@Konstanti said in IPsec VTI pfSense to UniFi:

@kriechmaden
Hi
ifconfig does not show that the vti tunnel is up (There is no vti tunnel in the list of interfaces, ipsec1000, for example)
This is the output of ifconfig on my PFSense .
enc0: flags=41<UP,RUNNING> metric 0 mtu 1536
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
groups: enc
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
inet 127.0.0.1 netmask 0xff000000
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
groups: lo
pflog0: flags=100<PROMISC> metric 0 mtu 33160
groups: pflog
pfsync0: flags=0<> metric 0 mtu 1500
groups: pfsync
syncpeer: 224.0.0.240 maxupd: 128 defer: on
syncok: 1
ipsec1000: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1400
tunnel inet 10.3.100.1 --> 10.3.100.100
inet6 fe80::a00:27ff:fe02:c8c1%ipsec1000 prefixlen 64 scopeid 0x7
inet 10.6.106.1 --> 10.6.106.2 netmask 0xfffffffc
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
reqid: 1000
groups: ipsec

[2.4.4-RELEASE][root@fw1]/root: ifconfig vtnet0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=c00b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO,LINKSTATE> ether 02:00:00:ef:85:e6 hwaddr 02:00:00:ef:85:e6 inet6 fe80::ff:feef:85e6%vtnet0 prefixlen 64 scopeid 0x1 inet6 XXXX:XXXX:XXXX:XXXX::3 prefixlen 64 inet6 XXXX:XXXX:XXXX:XXXX::2 prefixlen 64 vhid 3 inet XXX.XXX.XXX.114 netmask 0xfffffff0 broadcast XXX.XXX.XXX.XXX inet XXX.XXX.XXX.115 netmask 0xfffffff0 broadcast XXX.XXX.XXX.XXX vhid 5 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> media: Ethernet 10Gbase-T <full-duplex> status: active carp: MASTER vhid 3 advbase 1 advskew 0 carp: MASTER vhid 5 advbase 1 advskew 0 vtnet1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=c00b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO,LINKSTATE> ether 26:88:14:13:f6:c0 hwaddr 26:88:14:13:f6:c0 inet6 fe80::2488:14ff:fe13:f6c0%vtnet1 prefixlen 64 scopeid 0x2 inet6 fd60:fef5:50c0:e3fc::2 prefixlen 64 inet6 fd60:fef5:50c0:e3cf::1 prefixlen 64 vhid 4 inet 10.0.0.2 netmask 0xfffffc00 broadcast 10.0.3.255 inet 10.0.0.1 netmask 0xfffffc00 broadcast 10.0.3.255 vhid 1 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> media: Ethernet 10Gbase-T <full-duplex> status: active carp: MASTER vhid 1 advbase 1 advskew 0 carp: MASTER vhid 4 advbase 1 advskew 0 vtnet2: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=c00b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO,LINKSTATE> ether 72:df:07:2c:37:6b hwaddr 72:df:07:2c:37:6b inet6 fe80::70df:7ff:fe2c:376b%vtnet2 prefixlen 64 scopeid 0x3 inet6 fdf5:3371:813a:5aac::2 prefixlen 64 inet6 fdf5:3371:813a:5aac::1 prefixlen 64 vhid 7 inet 10.0.8.2 netmask 0xfffffc00 broadcast 10.0.11.255 inet 10.0.8.1 netmask 0xfffffc00 broadcast 10.0.11.255 vhid 6 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> media: Ethernet 10Gbase-T <full-duplex> status: active carp: MASTER vhid 6 advbase 1 advskew 0 carp: MASTER vhid 7 advbase 1 advskew 0 enc0: flags=41<UP,RUNNING> metric 0 mtu 1536 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> groups: enc lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6> inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet 127.0.0.1 netmask 0xff000000 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> groups: lo pflog0: flags=100<PROMISC> metric 0 mtu 33160 groups: pflog pfsync0: flags=41<UP,RUNNING> metric 0 mtu 1500 groups: pfsync pfsync: syncdev: vtnet1 syncpeer: 10.0.0.3 maxupd: 128 defer: off syncok: 1 ovpns1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500 options=80000<LINKSTATE> inet6 fe80::10d4:df6d:5e75:438d%ovpns1 prefixlen 64 scopeid 0x8 inet6 fd75:6d19:84ae:d2c9::1 prefixlen 64 inet 10.0.252.1 --> 10.0.252.2 netmask 0xffffffff nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> groups: tun openvpn Opened by PID 87483 ovpns2: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500 options=80000<LINKSTATE> inet6 fe80::10d4:df6d:5e75:438d%ovpns2 prefixlen 64 scopeid 0x9 inet6 fd9f:17e9:b703:fb61::1 prefixlen 64 inet 10.0.248.1 --> 10.0.248.2 netmask 0xffffffff nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> groups: tun openvpn Opened by PID 92953 ovpns3: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500 options=80000<LINKSTATE> inet6 fe80::10d4:df6d:5e75:438d%ovpns3 prefixlen 64 scopeid 0xa inet6 fd27:dd3e:7e8e:d32e::1 prefixlen 64 inet 10.0.244.1 --> 10.0.244.2 netmask 0xffffffff nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> groups: tun openvpn Opened by PID 11769 ovpns4: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500 options=80000<LINKSTATE> inet6 fe80::10d4:df6d:5e75:438d%ovpns4 prefixlen 64 scopeid 0xb inet6 fd7d:a519:4cbf:b745::1 prefixlen 64 inet 10.255.243.241 --> 10.255.243.242 netmask 0xffffffff nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> groups: tun openvpn Opened by PID 18031 ipsec1000: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500 tunnel inet XXX.XXX.XXX.114 --> XXX.XXX.XXX.253 inet6 fe80::10d4:df6d:5e75:438d%ipsec1000 prefixlen 64 scopeid 0xc inet 10.252.243.242 --> 10.252.243.243 netmask 0xfffffff0 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> reqid: 1000 groups: ipsec

Very strange the tunnel is now up and it seems to be working.
Niw the problem is, that if we ping the other site no response from the host is coming. But on a tcpdum we see, that the ICMP reuqest was received and the echo is send.

Ping from UniFi to pfSense:

tcpdump on the pfSense

[2.4.4-RELEASE][root@fw1]/root: tcpdump -i ipsec1000 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ipsec1000, link-type NULL (BSD loopback), capture size 262144 bytes 16:09:14.055108 IP ip114.ip-51-75-157.eu > 10.1.0.2: ICMP echo request, id 34846, seq 51345, length 44 16:09:14.148584 IP 10.252.243.242 > 10.252.243.243: ICMP echo request, id 2268, seq 997, length 8 16:09:14.248284 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 27647, seq 10, length 64 16:09:14.248326 IP 10.252.243.242 > 10.252.243.243: ICMP echo reply, id 27647, seq 10, length 64 16:09:14.388477 IP ip114.ip-51-75-157.eu > 10.1.0.2: ICMP echo request, id 34846, seq 51346, length 44 16:09:14.568088 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 223, length 64 16:09:14.568148 IP 10.252.243.242 > 10.252.243.243: ICMP echo reply, id 19207, seq 223, length 64 16:09:14.659358 IP 10.252.243.242 > 10.252.243.243: ICMP echo request, id 2268, seq 998, length 8 16:09:15.055940 IP ip114.ip-51-75-157.eu > 10.1.0.2: ICMP echo request, id 34846, seq 51348, length 44 16:09:15.169418 IP 10.252.243.242 > 10.252.243.243: ICMP echo request, id 2268, seq 999, length 8 16:09:15.249018 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 27647, seq 11, length 64 16:09:15.249038 IP 10.252.243.242 > 10.252.243.243: ICMP echo reply, id 27647, seq 11, length 64 16:09:15.389457 IP ip114.ip-51-75-157.eu > 10.1.0.2: ICMP echo request, id 34846, seq 51349, length 44 16:09:15.569286 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 224, length 64 16:09:15.569363 IP 10.252.243.242 > 10.252.243.243: ICMP echo reply, id 19207, seq 224, length 64 16:09:15.690172 IP 10.252.243.242 > 10.252.243.243: ICMP echo request, id 2268, seq 1000, length 8 16:09:16.057022 IP ip114.ip-51-75-157.eu > 10.1.0.2: ICMP echo request, id 34846, seq 51351, length 44 16:09:16.227717 IP 10.252.243.242 > 10.252.243.243: ICMP echo request, id 2268, seq 1001, length 8 16:09:16.248121 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 27647, seq 12, length 64 16:09:16.248179 IP 10.252.243.242 > 10.252.243.243: ICMP echo reply, id 27647, seq 12, length 64 16:09:16.390299 IP ip114.ip-51-75-157.eu > 10.1.0.2: ICMP echo request, id 34846, seq 51352, length 44 16:09:16.578063 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 225, length 64 16:09:16.578156 IP 10.252.243.242 > 10.252.243.243: ICMP echo reply, id 19207, seq 225, length 64 16:09:16.764230 IP 10.252.243.242 > 10.252.243.243: ICMP echo request, id 2268, seq 1002, length 8 ^C 24 packets captured 24 packets received by filter 0 packets dropped by kernel [2.4.4-RELEASE][root@fw1]/root: tcpdump -i enc0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on enc0, link-type ENC (OpenBSD encapsulated IP), capture size 262144 bytes 16:09:22.578118 (authentic,confidential): SPI 0xc24b31ec: IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 231, length 64 16:09:22.578170 (authentic,confidential): SPI 0xc7901687: IP 10.252.243.242 > 10.252.243.243: ICMP echo reply, id 19207, seq 231, length 64 16:09:23.049116 (authentic,confidential): SPI 0xc7901687: IP 10.252.243.242 > 10.252.243.243: ICMP echo request, id 2268, seq 1014, length 8 16:09:23.054739 (authentic,confidential): SPI 0xc7901687: IP ip114.ip-51-75-157.eu > 10.1.0.2: ICMP echo request, id 34846, seq 51372, length 44 16:09:23.247988 (authentic,confidential): SPI 0xc24b31ec: IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 27647, seq 19, length 64 16:09:23.248049 (authentic,confidential): SPI 0xc7901687: IP 10.252.243.242 > 10.252.243.243: ICMP echo reply, id 27647, seq 19, length 64 16:09:23.388236 (authentic,confidential): SPI 0xc7901687: IP ip114.ip-51-75-157.eu > 10.1.0.2: ICMP echo request, id 34846, seq 51373, length 44 16:09:23.563408 (authentic,confidential): SPI 0xc7901687: IP 10.252.243.242 > 10.252.243.243: ICMP echo request, id 2268, seq 1015, length 8 16:09:23.577872 (authentic,confidential): SPI 0xc24b31ec: IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 232, length 64 16:09:23.577917 (authentic,confidential): SPI 0xc7901687: IP 10.252.243.242 > 10.252.243.243: ICMP echo reply, id 19207, seq 232, length 64 16:09:24.055579 (authentic,confidential): SPI 0xc7901687: IP ip114.ip-51-75-157.eu > 10.1.0.2: ICMP echo request, id 34846, seq 51375, length 44 16:09:24.077415 (authentic,confidential): SPI 0xc7901687: IP 10.252.243.242 > 10.252.243.243: ICMP echo request, id 2268, seq 1016, length 8 ^C 12 packets captured 12 packets received by filter 0 packets dropped by kernel

ping command on the UniFi site:

device-admin@USG-PRO1:~$ ping 10.252.243.242 PING 10.252.243.242 (10.252.243.242) 56(84) bytes of data. ^C^C --- 10.252.243.242 ping statistics --- 31 packets transmitted, 0 received, 100% packet loss, time 30050ms device-admin@USG-PRO1:~$ ping 10.252.243.243 PING 10.252.243.243 (10.252.243.243) 56(84) bytes of data. 64 bytes from 10.252.243.243: icmp_req=1 ttl=64 time=0.146 ms 64 bytes from 10.252.243.243: icmp_req=2 ttl=64 time=0.125 ms 64 bytes from 10.252.243.243: icmp_req=3 ttl=64 time=0.148 ms 64 bytes from 10.252.243.243: icmp_req=4 ttl=64 time=0.113 ms ^C --- 10.252.243.243 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3000ms rtt min/avg/max/mdev = 0.113/0.133/0.148/0.014 ms

Ping from pfSense to UniFi:

tcpdump on UniFi:

root@USG-PRO1:~# tcpdump -i vti64 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vti64, link-type RAW (Raw IP), capture size 262144 bytes 16:11:21.689119 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 350, length 64 16:11:22.688719 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 351, length 64 16:11:23.689212 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 352, length 64 16:11:24.688916 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 353, length 64 16:11:25.690202 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 354, length 64 16:11:26.699178 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 355, length 64 16:11:27.699096 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 356, length 64 16:11:28.699099 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 357, length 64 16:11:29.709125 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 358, length 64 16:11:30.709099 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 359, length 64 16:11:31.719095 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 360, length 64 16:11:32.720917 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 361, length 64 16:11:33.729182 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 362, length 64 16:11:34.739091 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 363, length 64 16:11:35.739018 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 364, length 64 16:11:36.739108 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 365, length 64 16:11:37.749104 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 366, length 64 16:11:38.749143 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 367, length 64 16:11:39.749049 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 368, length 64 16:11:40.759056 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 369, length 64 16:11:41.759098 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 370, length 64 16:11:42.759097 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 371, length 64 16:11:43.759065 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 372, length 64 16:11:44.759087 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 373, length 64 16:11:45.759073 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 374, length 64 16:11:46.759099 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 375, length 64 16:11:47.760307 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 376, length 64 16:11:48.772532 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 377, length 64 16:11:49.779243 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 378, length 64 16:11:50.789094 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 379, length 64 16:11:51.789082 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 380, length 64 16:11:52.789099 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 381, length 64 16:11:53.789073 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 382, length 64 16:11:54.789129 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 383, length 64 16:11:55.788908 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 384, length 64 16:11:56.788971 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 385, length 64 16:11:57.789097 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 386, length 64 16:11:58.789057 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 387, length 64 16:11:59.789097 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 388, length 64 16:12:00.789103 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 389, length 64 16:12:01.789119 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 390, length 64 16:12:02.789123 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 391, length 64 16:12:03.789111 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 392, length 64 16:12:04.789085 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 393, length 64 16:12:05.789154 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 394, length 64 16:12:06.789099 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 395, length 64 16:12:07.789096 IP 10.252.243.243 > 10.252.243.242: ICMP echo request, id 19207, seq 396, length 64 ^C 47 packets captured 47 packets received by filter 0 packets dropped by kernel

Ping command on pfSense:

[2.4.4-RELEASE][root@fw1]/root: ping 10.252.243.243 PING 10.252.243.243 (10.252.243.243): 56 data bytes ^C --- 10.252.243.243 ping statistics --- 10 packets transmitted, 0 packets received, 100.0% packet loss [2.4.4-RELEASE][root@fw1]/root: ping 10.252.243.242 PING 10.252.243.242 (10.252.243.242): 56 data bytes ^C --- 10.252.243.242 ping statistics --- 15 packets transmitted, 0 packets received, 100.0% packet loss

The CVE was way way way more hyped than it should be. 100% a routing issue and not a "fault" at VPNs. https://github.com/stryngs/hysteria << For the answers