Morning All,
I figured this out - I had a NAT rule which was capturing the traffic and changing the source address, as a result it didn't encapsulate it. Thanks Joe. From: Madden, Joe Sent: 09 July 2018 09:24 To: [email protected] Subject: LibreSwan not generating ESP packets (Not Encapsulating) Morning All, We have a VPN connection that appears to be established to a third party with a successful connection, however we can't seem to get any traffic flow to pass over the network. Ipsec Verify passed ok: Verifying installed system and configuration files Version check and ipsec on-path [OK] Libreswan 3.23 (netkey) on 3.10.0-693.21.1.el7.x86_64 Checking for IPsec support in kernel [OK] NETKEY: Testing XFRM related proc values ICMP default/send_redirects [OK] ICMP default/accept_redirects [OK] XFRM larval drop [OK] Pluto ipsec.conf syntax [OK] Two or more interfaces found, checking IP forwarding [OK] Checking rp_filter [OK] Checking that pluto is running [OK] Pluto listening for IKE on udp 500 [OK] Pluto listening for IKE/NAT-T on udp 4500 [OK] Pluto ipsec.secret syntax [OK] Checking 'ip' command [OK] Checking 'iptables' command [OK] Checking 'prelink' command does not interfere with FIPS [OK] Checking for obsolete ipsec.conf options [OK] And the VPN seems to be established: 000 "ipsec-1": 192.168.142.132/32===51.148.60.157<51.148.60.157>---51.148.60.158...87.242.152.6<87.242.152.6>===10.0.22.3/32; erouted; eroute owner: #2 000 "ipsec-1": oriented; my_ip=unset; their_ip=unset; my_updown=ipsec _updown; 000 "ipsec-1": xauth us:none, xauth them:none, my_username=[any]; their_username=[any] 000 "ipsec-1": our auth:secret, their auth:secret 000 "ipsec-1": modecfg info: us:none, them:none, modecfg policy:push, dns:unset, domains:unset, banner:unset, cat:unset; 000 "ipsec-1": labeled_ipsec:no; 000 "ipsec-1": policy_label:unset; 000 "ipsec-1": ike_life: 86400s; ipsec_life: 28800s; replay_window: 32; rekey_margin: 180s; rekey_fuzz: 100%; keyingtries: 0; 000 "ipsec-1": retransmit-interval: 500ms; retransmit-timeout: 60s; 000 "ipsec-1": sha2-truncbug:no; initial-contact:no; cisco-unity:no; fake-strongswan:no; send-vendorid:no; send-no-esp-tfc:no; 000 "ipsec-1": policy: PSK+ENCRYPT+TUNNEL+PFS+UP+IKEV2_ALLOW+IKEV2_PROPOSE+SAREF_TRACK+IKE_FRAG_ALLOW+ESN_NO; 000 "ipsec-1": conn_prio: 32,32; interface: eno1; metric: 0; mtu: unset; sa_prio:auto; sa_tfc:none; 000 "ipsec-1": nflog-group: unset; mark: unset; vti-iface:unset; vti-routing:no; vti-shared:no; nic-offload:auto; 000 "ipsec-1": our idtype: ID_IPV4_ADDR; our id=51.148.60.157; their idtype: ID_IPV4_ADDR; their id=87.242.152.6 000 "ipsec-1": dpd: action:restart; delay:30; timeout:120; nat-t: encaps:auto; nat_keepalive:yes; ikev1_natt:both 000 "ipsec-1": newest ISAKMP SA: #1; newest IPsec SA: #2; 000 "ipsec-1": IKE algorithms: AES_CBC_256-HMAC_SHA2_256-DH19 000 "ipsec-1": IKEv2 algorithm newest: AES_CBC_256-HMAC_SHA2_256-DH19 000 "ipsec-1": ESP algorithms: AES_CBC_256-HMAC_SHA2_256_128 000 "ipsec-1": ESP algorithm newest: AES_CBC_256-HMAC_SHA2_256_128; pfsgroup=<Phase1> 000 000 Total IPsec connections: loaded 1, active 1 000 000 State Information: DDoS cookies not required, Accepting new IKE connections 000 IKE SAs: total(1), half-open(0), open(0), authenticated(1), anonymous(0) 000 IPsec SAs: total(1), authenticated(1), anonymous(0) 000 000 #1: "ipsec-1":500 STATE_PARENT_I3 (PARENT SA established); EVENT_SA_REPLACE in 85992s; newest ISAKMP; idle; import:admin initiate 000 #2: "ipsec-1":500 STATE_V2_IPSEC_I (IPsec SA established); EVENT_SA_REPLACE in 28322s; newest IPSEC; eroute owner; isakmp#1; idle; import:admin initiate 000 #2: "ipsec-1" [email protected]<mailto:[email protected]> [email protected]<mailto:[email protected]> [email protected]<mailto:[email protected]> [email protected]<mailto:[email protected]> ref=0 refhim=0 Traffic: ESPin=0B ESPout=0B! ESPmax=0B Our config as follows: conn ipsec-1 authby= secret auto= start type= tunnel forceencaps= no rekeymargin= 3m keyingtries= %forever salifetime= 8h ikelifetime= 24h ikev2= insist #RTT left= 51.148.60.157 leftsubnet= 192.168.142.132/32 leftid= 51.148.60.157 leftnexthop= 51.148.60.158 #SAA right= 87.242.152.6 rightid= 87.242.152.6 rightsubnet= 10.0.22.3/32 #Key Settings ike= aes256-sha2_256;dh19 phase2= esp phase2alg= aes256-sha2_256 pfs= yes sha2_truncbug= no #Dead Peer Detection dpdaction= restart dpddelay= 30 dpdtimeout= 120 Secrets file: 51.148.60.157 87.242.152.6: PSK "######" Ipsec.conf config setup # which IPsec stack to use, "netkey" (the default), "klips" or "mast". # For MacOSX use "bsd" protostack=netkey # # Normally, pluto logs via syslog. If you want to log to a file, # specify below or to disable logging, eg for embedded systems, use # the file name /dev/null # Note: SElinux policies might prevent pluto writing to a log file at # an unusual location. #logfile=/var/log/pluto.log # # Do not enable debug options to debug configuration issues! # # plutodebug "all", "none" or a combation from below: # "raw crypt parsing emitting control controlmore kernel pfkey # natt x509 dpd dns oppo oppoinfo private". # Note: "private" is not included with "all", as it can show confidential # information. It must be specifically specified # examples: # plutodebug="control parsing" # plutodebug="all crypt" # Again: only enable plutodebug when asked by a developer # plutodebug=all # # Enable core dumps (might require system changes, like ulimit -C) # This is required for abrtd to work properly # Note: SElinux policies might prevent pluto writing the core at # unusual locations dumpdir=/var/run/pluto/ # # NAT-TRAVERSAL support # exclude networks used on server side by adding %v4:!a.b.c.0/24 # It seems that T-Mobile in the US and Rogers/Fido in Canada are # using 25/8 as "private" address space on their wireless networks. # This range has never been announced via BGP (at least up to 2015) virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:25.0.0.0/8,%v4:100.64.0.0/10 #virtual_private= # For example connections, see your distribution's documentation directory, # or https://libreswan.org/wiki/ # # There is also a lot of information in the manual page, "man ipsec.conf" # # It is best to add your IPsec connections as separate files in /etc/ipsec.d/ include /etc/ipsec.d/*.conf For some reason the VPN establishes OK as far as I can see. We try from 192.168.142.132 to connect to a webservice on 10.0.22.3/32 but it times out, a TCPdump - tcpdump -i eno1 -nnvvv \(port 500 or port 4500 or proto 50\) - on interface 51.148.60.157 shows no esp or 4500 being sent as we attempt a request. Does anyone have any ideas what can cause this? It like the Interesting traffic is not being detected correctly? Cheers Joe
_______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
