OPNsense Forum
Archive => 17.1 Legacy Series => Topic started by: kug1977 on February 28, 2017, 05:02:40 pm
-
Hi,
I've been trying to setup a IPsec tunnel and it was short working with OPNsense 17.1.1, but stopped again with OPNsense 17.1.2. The tunnel come up fine, but I can't put traffic through the tunnel (incl. PING). And now I'm at the end of my knowledge regarding IPsec and have to bother the forum members with my issue.
I've the following setup
Site A: DSL with the name gw1.dyndns.net (the DynDSN is working and result in the right DNS name)
Site B: DSL with the name gw2.dyndns.net (the DynDSN is working and result in the right DNS name)
phase1: IKEv2, Main Mode, NAT Enabled, MOBIKE disabled
phase2: will connect o lot of VLANs that are created on both sites. For test purposes I cut it down to ONE child SA.
I've been setting sysctl on both gateways the same way:
net.inet.ipsec.def_policy: 1
net.inet.ipsec.esp_trans_deflev: 1
net.inet.ipsec.esp_net_deflev: 1
net.inet.ipsec.ah_trans_deflev: 1
net.inet.ipsec.ah_net_deflev: 1
net.inet.ipsec.ah_cleartos: 1
net.inet.ipsec.ah_offsetmask: 0
net.inet.ipsec.dfbit: 0
net.inet.ipsec.ecn: 0
net.inet.ipsec.debug: 0
net.inet.ipsec.ipsecstats: Format:I Length:128 Dump:0x00000000000000000000000000000000...
net.inet.ipsec.crypto_support: 50331648
net.inet.ipsec.filtertunnel: 1
This is how apices status looks on gw2.dyndns.net
Status of IKE charon daemon (strongSwan 5.5.1, FreeBSD 11.0-RELEASE-p7, amd64):
uptime: 3 minutes, since Feb 28 18:00:02 2017
worker threads: 10 of 16 idle, 6/0/0/0 working, job queue: 0/0/0/0, scheduled: 4
loaded plugins: charon aes des blowfish rc2 sha2 sha1 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf xcbc cmac hmac gcm attr kernel-pfkey kernel-pfroute resolve socket-default stroke vici updown eap-identity eap-md5 eap-mschapv2 eap-radius eap-tls eap-ttls eap-peap xauth-generic whitelist addrblock
Listening IP addresses:
10.0.2.129
87.180.85.216
Connections:
con1: 87.180.85.216...gw1.dyndns.net IKEv2, dpddelay=10s
con1: local: [87.180.85.216] uses pre-shared key authentication
con1: remote: [178.24.49.155] uses pre-shared key authentication
con1: child: 10.0.2.128/25 === 10.0.2.0/25 TUNNEL, dpdaction=clear
Security Associations (1 up, 0 connecting):
con1[1]: ESTABLISHED 3 minutes ago, 87.180.85.216[87.180.85.216]...178.24.49.155[178.24.49.155]
con1[1]: IKEv2 SPIs: 50508ca22749bb8b_i* 4089c57de2e38c5a_r, pre-shared key reauthentication in 3 hours
con1[1]: IKE proposal: BLOWFISH_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_4096
con1{1}: INSTALLED, TUNNEL, reqid 1, ESP SPIs: c92fbb12_i c655083e_o
con1{1}: AES_GCM_16_128, 0 bytes_i (0 pkts, 183s ago), 0 bytes_o, rekeying in 44 minutes
con1{1}: 10.0.2.128/25 === 10.0.2.0/25
root@gw2:~ # ipsec up con1
establishing CHILD_SA con1
generating CREATE_CHILD_SA request 45 [ N(ESP_TFC_PAD_N) SA No KE TSi TSr ]
sending packet: from 87.180.85.216[500] to 178.24.49.155[500] (464 bytes)
received packet: from 178.24.49.155[500] to 87.180.85.216[500] (464 bytes)
parsed CREATE_CHILD_SA response 45 [ N(ESP_TFC_PAD_N) SA No KE TSi TSr ]
received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
CHILD_SA con1{2} established with SPIs c0e90bb1_i ce7ab7b5_o and TS 10.0.2.128/25 === 10.0.2.0/25
connection 'con1' established successfully
On both sides the FW IPsec section allows all traffic to pass. I've setup a outgoing rule to prevent local packets leaving on WAN (https://www.infotechwerx.com/blog/Prevent-Any-Traffic-VPN-Hosts-Egressing-WAN), which triggers on PING from gw2 to gw1 (10.0.2.1) :
ping: sendto: Operation not permitted
I see also no traffic passing into our out of the tunnel in the VPN>IPsec>Status Overview on both sides. But I've been seeing the packages blogged in the FW logs by this rule. (Disabling the rule make IPsec not working.)
Can someone help to create a tunnel in my network, please? Or at least give me some more steps to troubleshoot?
King regards,
Kay-Uwe
-
I will report, that I get IPsec tunnel working with 17.1.6 again. I'm not sure when it was changed and whether the issue was not my fault. For documentation, when tunnel is shown in OPNsense as established, try to ping the other site from a client behind the FW or by setting the right source on the firewall
ping -S <Interface IP on the Source FW> <destination IP>