[SOLVED] libreswan apparently not listening on port udp/500
Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
And while bringing up the connection it stops at phase2
Code:
[root@localhost:~] # ipsec auto --up conn_name
002 "conn_name" #193: initiating Main Mode
104 "conn_name" #193: STATE_MAIN_I1: initiate
003 "conn_name" #193: received Vendor ID payload [RFC 3947]
003 "conn_name" #193: received Vendor ID payload [FRAGMENTATION c0000000]
002 "conn_name" #193: enabling possible NAT-traversal with method RFC 3947 (NAT-Traversal)
002 "conn_name" #193: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
106 "conn_name" #193: STATE_MAIN_I2: sent MI2, expecting MR2
003 "conn_name" #193: received Vendor ID payload [Cisco-Unity]
003 "conn_name" #193: received Vendor ID payload [XAUTH]
003 "conn_name" #193: ignoring unknown Vendor ID payload [7af4f6652a64a1e60220e4563d6b8452]
003 "conn_name" #193: ignoring Vendor ID payload [Cisco VPN 3000 Series]
003 "conn_name" #193: NAT-Traversal: Result using RFC 3947 (NAT-Traversal) sender port 500: no NAT detected
002 "conn_name" #193: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
108 "conn_name" #193: STATE_MAIN_I3: sent MI3, expecting MR3
003 "conn_name" #193: received Vendor ID payload [Dead Peer Detection]
002 "conn_name" #193: Main mode peer ID is ID_IPV4_ADDR: '4.3.2.1'
002 "conn_name" #193: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4
004 "conn_name" #193: STATE_MAIN_I4: ISAKMP SA established {auth=PRESHARED_KEY cipher=aes_256 integ=sha group=MODP1024}
002 "conn_name" #194: initiating Quick Mode PSK+ENCRYPT+TUNNEL+UP+IKEV1_ALLOW+IKEV2_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW {using isakmp#193 msgid:c76d27fc proposal=AES(12)_256-SHA1(2)_000 pfsgroup=no-pfs}
117 "conn_name" #194: STATE_QUICK_I1: initiate
010 "conn_name" #194: STATE_QUICK_I1: retransmission; will wait 500ms for response
010 "conn_name" #194: STATE_QUICK_I1: retransmission; will wait 1000ms for response
010 "conn_name" #194: STATE_QUICK_I1: retransmission; will wait 2000ms for response
010 "conn_name" #194: STATE_QUICK_I1: retransmission; will wait 4000ms for response
010 "conn_name" #194: STATE_QUICK_I1: retransmission; will wait 8000ms for response
010 "conn_name" #194: STATE_QUICK_I1: retransmission; will wait 16000ms for response
010 "conn_name" #194: STATE_QUICK_I1: retransmission; will wait 32000ms for response
031 "conn_name" #194: max number of retransmissions (8) reached STATE_QUICK_I1. No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
000 "conn_name" #194: starting keying attempt 2 of an unlimited number, but releasing whack
[root@localhost:~] # cat /etc/ipsec.conf
# /etc/ipsec.conf - Libreswan IPsec configuration file
# This file: /etc/ipsec.conf
#
# Enable when using this configuration file with openswan instead of libreswan
#version 2
#
# Manual: ipsec.conf.5
# basic configuration
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
#
# The interfaces= line is only required for the klips/mast stack
#interfaces="%defaultroute"
#interfaces="ipsec0=eth0 ipsec1=ppp0"
#
# If you want to limit listening on a single IP - not required for
# normal operation
#listen=127.0.0.1
#
# Do not set debug options to debug configuration issues!
#
# plutodebug / klipsdebug = "all", "none" or a combation from below:
# "raw crypt parsing emitting control kernel pfkey natt x509 dpd
# private".
# Note: "crypt" 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 or klipsdebug when asked by a developer
#plutodebug=none
#klipsdebug=none
#
# 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 upto 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,%v6:fd00::/8,%v6:fe80::/10
# 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
[root@localhost:~] # cat /etc/ipsec.d/conn_name.conf
conn conn_name
left=1.2.3.4
leftsubnet=192.168.73.0/24
right=4.3.2.1
rightsubnet=172.26.64.0/24
auto=start
authby=secret
ike=aes256-sha1
ikelifetime=86400
phase2=esp
phase2alg=aes256-sha1
salifetime=3600
pfs=no
[root@localhost:~] # cat /etc/ipsec.secrets
include /etc/ipsec.d/*.secrets
[root@localhost:~] # cat /etc/ipsec.d/conn_name.secrets
%any %any : PSK "secret"
The post is already long with the output and log extracts, sorry for that.
To not add more, know that the firewall allows all ipsec entries.
And I have to assume, at least for the moment, that the other VPN peer (on which I have no access so far) is fine.
Any clue why the udp/500 port vanishes on ss and why the connection does not come up?
Well, remember that UDP is a datagram protocol, not a socket protocol. It might be listening for incoming packets with this port-number and it might be sending them, but there is no concept of a TCP/IP "socket" that is established with a particular destination and then later torn-down.
A UDP message is simply sent. It is not a two-way connection. There is no guarantee that the packet, once sent, will be received at all, neither in any particular sequence, unlike TCP/IP sockets.
Indeed, there two main reasons why VPNs commonly use UDP:
They don't take up a socket, so they stay out of the way of the (usually, socket-based) communications that they support.
A TCP/IP port scan won't detect an open socket. In the case of OpenVPN with its tls-auth feature, the server can simply drop an incoming packet and thereby remain incognito.
It is always an option to use TCP/IP for the intra-VPN-server connections, but this is not customarily done.
- - - - -
It sounds to me like, in the case at bar, the traffic simply isn't getting through to its destination. Do a traceroute from each of the locations to each of the others, to make sure that the round trip(!) connection routing is as you expect it to be. tcpdump should show the encrypted packets "in flight."
Last edited by sundialsvcs; 02-22-2017 at 09:12 AM.
I had indeed confirmed with tcpdump that requests and corresponding responses are going through.
I do understand the there is no "listening to" UDP socket under port 500.
The strange part is that
Code:
ss -ulnp | grep -w 53
clearly reports something for UDP Bind setup,
but still nothing for VPN with
Code:
ss -ulnp | grep -w 500
At this stage I have made progress.
But still my VPN is not up.
And I want first make sure I fully understand the settings at my local side, and that they are all ok and good.
I will then later get in touch with the administrator at the remote side to troubleshoot together.
I know for sure that ipsec is bound to port udp/500, as shown by lsof and that independently from ss (or netstat) output.
I also confirmed that by capturing tcpdump traces clearly showing meaningful exchanges on port udp/500.
Finally, I have succeeded to bring up the IPsec Security Associations. The problem in my configuration was in rightsubnet not matching what the remote end expected.
I still have firewall and routing problems, but that is for another thread, maybe.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
