IPsec

• B

  Random IPSec disconnects
  • bbiketa  

  2
  0
  Votes
  2
  Posts
  91
  Views

  C

  me too
• G

  PFsense box can't ping WAN IP of IPSEC remote gateway
  • grantems  

  1
  0
  Votes
  1
  Posts
  22
  Views

  No one has replied

• N

  DNS queries trough ipsec
  • nikkopegmail.com  

  3
  0
  Votes
  3
  Posts
  43
  Views

  N

  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
• S

  Dashboard IPsec Widget dose not work
  • Secarius  

  6
  0
  Votes
  6
  Posts
  27
  Views

  S

  @kiokoman thx your right
• S

  IPsec restrict a specific mobile client to access the LAN
  • Stefan Milev  

  1
  0
  Votes
  1
  Posts
  22
  Views

  No one has replied

• V

  IKEv2 Policy Match Error on Windows 10 Client
  • VioSpeed  

  6
  0
  Votes
  6
  Posts
  251
  Views

  V

  Just an update if others come across this. I have now successfully connected using IKEv2. What I did was change the phase 1 remote gateway from "any" to our public IP address. I noticed in the /var/etc/ipsec/ipsec.conf file that the "left" IP was listening on our internal WAN IP on the WAN interface rather than the public IP address. conn con-mobile fragmentation = yes keyexchange = ikev2 reauth = yes forceencaps = no mobike = no rekey = yes installpolicy = yes type = tunnel dpdaction = clear dpddelay = 10s dpdtimeout = 60s auto = add left = 10.x.x.x
• Y

  IPSEC low throughput
  • Yazur  

  5
  0
  Votes
  5
  Posts
  114
  Views

  Y

  UP
• I

  Pfsense IPSec IKEv2 Tunnel to Azure - Traffic not routed to azure except from pfsense itself
  • igel2805  

  1
  0
  Votes
  1
  Posts
  46
  Views

  No one has replied

• J

  Azure Pfsense IPSEC tunnel to cell carrier - dropped traffic
  • jonathan.v  

  1
  0
  Votes
  1
  Posts
  34
  Views

  No one has replied

• C

  IPSec VTI no Entry in Routingtable
  • cmcologne  

  2
  0
  Votes
  2
  Posts
  26
  Views

  C

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

  IPsec tunnel pfSense - Fortigate disconnects and reconnects
  • ilGino  

  2
  0
  Votes
  2
  Posts
  84
  Views

  

  @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
• C

  no EAP key found for hosts RADIUS config for Mobile Ipsec VPN
  • cre8toruk  

  9
  0
  Votes
  9
  Posts
  73
  Views

  C

  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....
• 

  Changing IPsec VPN Ports
  • mohkhalifa  

  7
  0
  Votes
  7
  Posts
  94
  Views

  

  Thanks all for your kind replies appreciated
• M

  Gateway Monitoring gets stuck in infinite loop when using multiple VTIs on SG-3100
  • marcquark  

  5
  0
  Votes
  5
  Posts
  105
  Views

  M

  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.
• R

  (Solved) Vulnerability Scan Traffic through a VPN.
  • ricardo.aybar  

  2
  0
  Votes
  2
  Posts
  76
  Views

  R

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

  IPSEC not routing to LAN
  • normaluser99  

  4
  0
  Votes
  4
  Posts
  196
  Views

  D

  to route all the traffic though IPsec tunnel please follow the below configuration. you need firewall Aliases. you need virtual IP for DNS routing could be any Set the above virtual ip as DNS for vpn clients. hope this should work for you. Thanks Daman
• R

  Routed IPsec (VTI) to Azure - Does it work?
  • richard.gray  

  3
  0
  Votes
  3
  Posts
  278
  Views

  N

  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!
• J

  Failover IPSec tunnels with Gateway Groups
  • juicejug  

  2
  0
  Votes
  2
  Posts
  31
  Views

  

  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.
• R

  IPsec VPN StS - no traffic
  • Rafael Santos 92  

  1
  0
  Votes
  1
  Posts
  52
  Views

  No one has replied

• T

  IPSEC widget "empty" - freeradius assigned client ip
  • three  

  9
  0
  Votes
  9
  Posts
  51
  Views

  

  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.
• K

  IPsec VTI pfSense to UniFi
  ipsec unifi ubiquiti • • kriechmaden  

  4
  0
  Votes
  4
  Posts
  140
  Views

  K

  @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
• T

  CVE-2019-14899
  security • • tpearson-raptor  

  9
  0
  Votes
  9
  Posts
  941
  Views

  S

  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
• S

  Dual WAN and IPSEC
  • shubakas  

  2
  0
  Votes
  2
  Posts
  40
  Views

  S

  Sorry i find the solution I disable et enable IPSEC tunnels et it's ok Thaaaaanks
• N

  [IPSEC site-to-site] Subnets Connectivity
  • nomatter  

  32
  0
  Votes
  32
  Posts
  365
  Views

  

  @nomatter Thanks for the followup. I've not experimented with VTI source NAT before, and I'm surprised to see that it doesn't in fact work.
• D

  IPv6 IKEv1 tunnel not established if FQDN is used as Remote Gateway
  • dusan  

  4
  0
  Votes
  4
  Posts
  83
  Views

  D

  @jimp Thanks. I'm glad hearing that it is known and somebody is working on it. Can't wait for pfSense v2.5.
• R

  IPSec established but not work properly
  • rlozanogar  

  2
  0
  Votes
  2
  Posts
  50
  Views

  R

  Update: The remote network is 10.90.0.0/16. When this problem appears sometines i can do ping host in one VLan and not another host in another vlan. For example: When i do ping to host on vlan 6: 10.90.6.22/24 . The ping not work and when I do ping to VLan 19: 10.90.19.63 , the ping work. The problem with Vlans is random. I tried to disable DPD but the result is the same.
• R

  No internet access through VPN connection to pfsense
  • Richard.B.  

  4
  0
  Votes
  4
  Posts
  217
  Views

  R

  You are absolutely awesome! Thank you so much. I wasn't thinking of that. I disabled "pull routes", and it worked right away :-).
• E

  Site-to-Site Authentication Fails
  • Elegant  

  4
  0
  Votes
  4
  Posts
  135
  Views

  

  NAT will make that trickier but usually you can get around that by setting appropriate identifiers. I wouldn't use hostnames in those fields for identifiers, though. It isn't handled there like it is in the remote gateway field. Try setting the identifiers explicitly to a value on both sides and see what happens.
• A

  ipsec tunnel established but i see same isp ip address
  • akkiz  

  1
  0
  Votes
  1
  Posts
  38
  Views

  No one has replied

• L

  CLI Options to Re-establish Collapsed Tunnel
  • luxadmin  

  3
  0
  Votes
  3
  Posts
  39
  Views

  L

  @jimp Thanks! Will start digging into this.
• 

  IPsec (VTI) memory leak.
  • 0daymaster  

  3
  0
  Votes
  3
  Posts
  57
  Views

  

  @jimp So I don't have definitive proof but both my core router and branch router started swapping out. My branch router filled up its swap then crashed. My core router would have crashed also but it has 32 GB of RAM while my branch router only has 16 GB of RAM. The memory usage tracks exactly with the backup job. Core router memory overview including swap usage: Branch router memory overview including swap usage: For the time being I am moving all my tunnels that I can over to OpenVPN. This is unfortunate as OpenVPN does not get good performance and I have some remote sites with Fortigate firewalls. Fortigate does not support OpenVPN.
• D

  IPSec/ Road Warrior not working on pfsense2.4.4
  • damanb1  

  1
  0
  Votes
  1
  Posts
  42
  Views

  No one has replied

• O

  max number of ipsec tunnels for c3758 processor
  • ozlecz  

  7
  0
  Votes
  7
  Posts
  88
  Views

  L

  IOW the limitation is likely not the number of IPsec tunnels, but the total amount of traffic they carry, which will run into bandwidth limits or CPU encryption/decryption capacity limits, whichever comes first. You can realistically expect 400-900 Mbps of total encrypted traffic on that box, depending on traffic complexity. Hope this helps.
• M

  Problem with NAT on IPSEC for Networks not in Phase2
  • mario_b  

  1
  0
  Votes
  1
  Posts
  49
  Views

  No one has replied

• S

  Is it necessary to add the 4500(IPsec Nat-T) and 500 (ISAKmp) on the WAN?? pfsense 2.4.4
  • Sal  

  2
  0
  Votes
  2
  Posts
  88
  Views

  

  @Sal said in Is it necessary to add the 4500(IPsec Nat-T) and 500 (ISAKmp) on the WAN?? pfsense 2.4.4: I thought that the important part is to add the rules on the IPsec interface, not the WAN. Is this correct ?? Rules for 4500/500 on your IPSEC interface? Makes no sense. Those ports have to be working on your WAN so incoming IPSEC connections are passed through. On your tunnel/IPSEC interface those rules for those ports make no sense. But IMHO IPSec Ports are accepted automatically on WAN if IPSEC connections are configured. but I noticed that the tunnel is connected. IPSEC can be initiated bi-directional. So every side can be initiator or receiver. The tunnel coming up doesn't mean you already have working rules as it could have been initiated from the second site to the first your created the rules yourself. But as stated above, if I remember correctly IPSEC is created automatically (and that automation can be switched off in adv. settings)
• I

  Port-forward IPSec-Traffic
  • it_ib  

  1
  0
  Votes
  1
  Posts
  34
  Views

  No one has replied

• P

  IPsec rules to only allow specific pc's
  • p912s  

  1
  0
  Votes
  1
  Posts
  42
  Views

  No one has replied

• K

  IKEv2 to Windows10
  • killrob  

  11
  0
  Votes
  11
  Posts
  308
  Views

  K

  Hello, sorry for the delay! It works now perfect for me and I think it was a problem wit my mobile-connection. It works with the Android StrongSwan-App, with the default configuration on Windows 10 (IKEv2) and with the PowerShell generated connection mentioned by @lfoerster. Thank you Robert
• J

  One side pfsense behind NAT 1:1 and another as peer
  • joao.borges  

  8
  0
  Votes
  8
  Posts
  131
  Views

  J

  Someone? =/
• P

  IPsec Tunnel goes down with end of SA Lifetime - SOLVED!!!
  • p912s  

  5
  0
  Votes
  5
  Posts
  195
  Views

  P

  SOLVED!!!! Searching for answers I strumbled on another post that was having the same problem. And it pointed me to a problem in my setup… I had PFS enabled on the pfSense and disabled on the USG. Thanks to those that stopped to help, hopefully this post will help someone in the future. Scot