Description of problem: pluto binds to ALL interfaces despite --interface option use Version-Release number of selected component (if applicable): openswan-2.6.38 How reproducible: Always Steps to Reproduce: 1. only multi-interface host add 'plutoopts="--interface eth0"' to /etc/ipsec.conf 2. on another interface, eg eth1, run something with bind to isakmp port (eg vpnc) 3. start ipsec Actual results: 3. ipsec fails with "ipsec__plutorun: 003 FATAL ERROR: bind() failed in find_raw_ifaces4(). Errno 98: Address already in use" Expected results: 3. ipsec/pluto should run since is supposed to be binding to a single interface only Additional info: In sysdep_linux:find_raw_ifaces4() there is a pointless and wrong bind to isakmp port on ALL interfaces. The bind is pointless because it isn't necessary to bind a socket if one isn't going to send anything via it (only SIOCGIFCONF and SIOCGIFFLAGS ioctls are being done). And it is wrong because it totally ignores the command to only bind to explicitly specified interfaces with the pluto "--interface" command-line option.
Correction: "1. on multi-interface ..."
the interfaces= is really an option left from the KLIPS days where everything is routing based, and does not really apply to XFRM/NETKEY. The man page isn't entirely too clear about it but does mention it: interfaces virtual and physical interfaces for IPsec to use: a single virtual=physical pair, a (quoted!) list of pairs separated by white space, or %none. One of the pairs may be written as %defaultroute, which means: find the interface d that the default route points to, and then act as if the value was ``ipsec0=d''. %defaultroute is the default; %none must be used to denote no interfaces, or when using the NETKEY stack. If %defaultroute is used (implicitly or explicitly) information about the default route and its interface is noted for use by ipsec_auto(8).) That said, we should handle interface additions/removals and IP address addition/removal better. Did you mean to use --listen or listen= option instead of the interface option? listen IP address to listen on (default depends on interfaces= setting). Currently only accepts one IP address.
note that openswan in fedora 19 is obsoleted by libreswan.
Paul Wouters. I said "--interface" and I didn't say "interfaces=". Anyhow the documentation I see says: "(the --interface option can be used to limit the interfaces considered)" What I want to achieve is to have openswan only bind to a particular interface so that all traffic only goes via one particular interface. That doesn't sound what --listen does. Where does one put the ip address or interface name when one uses the --listen option? But would it matter if I used "--listen" instead? The fact is that the code does a bind on ALL INTERFACES. This will happen whether one uses "--listen" or "--interface". The problem with the (unnecessary) bind on all interfaces is that if you have something else listening on isakmp on an unrelated interface then it will make openswan fail. It is irrelevant whether one uses "--listen" or "--interface". Also if openswan is "obsoleted" then why is it included in the distribution? That doesn't match any known meaning of obsoleted!
The --interface option to pluto matches the interface= line in ipsec.conf Similarly, the --listen option to pluto matches the listen= line in ipsec.conf You can use plutoopts= with interface/listen but you should use the native option for that. plutoopts will vanish in a future libreswan version, as all pluto options will have "config setup" items in ipsec.conf If you run "yum install openswan" on Fedora 19, it should bring in libreswan. Please let me know if that's not the case for you. As I explained, the interface documentation only applies to KLIPS, not XFRM/NETKEY. The "consideration" is for binding the physical interface to the virtual ipsecX interface. XFRM/NETKEY does not use virtual interfaces. The listen= option does that you want: [root@west ~]# netstat -an |grep :500 [root@west ~]# grep listen /etc/ipsec.conf listen=192.1.2.45 [root@west ~]# ipsec setup start Redirecting to: systemctl start ipsec.service [root@west ~]# netstat -an |grep :500 udp 0 0 192.1.2.45:500 0.0.0.0:* [root@west ~]# nc -ul 500 & [1] 3013 [root@west ~]# netstat -an |grep :500 udp 0 0 0.0.0.0:500 0.0.0.0:* udp 0 0 192.1.2.45:500 0.0.0.0:*
This is a bug report about openswan. It is not a request to be guided on how to install some other software package. I have patched my version of to remove the offending bind() and now it works for me whereas previously it did not. And it does indeed correctly bind to the required interface using the "--interface" option. In any case your procedure above is broken. You need to have some other process listening on port 500 BEFORE you start ipsec and not AFTER like you have done. You also never answered my question: how does one specify an interface name or ip address with the --listen option?
1) openswan is no longer supported for Fedora/RHEL. It has been obsoleted by libreswan. The proper procedure for me would have been to close this as WONTFIX or change the component to libreswan. 2) It works fine the other way to: [root@west ~]# netstat -an |grep :500 [root@west ~]# nc -ul 192.9.4.45 500 ^Z [1]+ Stopped nc -ul 192.9.4.45 500 [root@west ~]# bg [1]+ nc -ul 192.9.4.45 500 & [root@west ~]# netstat -an |grep :500 udp 0 0 192.9.4.45:500 0.0.0.0:* [root@west ~]# grep listen /etc/ipsec.conf listen=192.1.2.45 [root@west ~]# ipsec setup start Redirecting to: systemctl start ipsec.service [root@west ~]# netstat -an |grep :500 udp 0 0 192.1.2.45:500 0.0.0.0:* udp 0 0 192.9.4.45:500 0.0.0.0:* [root@west ~]# 3) As I explained you can run pluto with --listen <ip address> or specify plutotopts="--listen ipaddress". but you should just specify listen=ipaddress in config setup in ipsec.conf. 4) if you want me to fix what you deem is your problem, please clarify your use case by something I can reproduce on my test machine.
Regarding 3). The documentation doesn't say there is any argument to the --listen option. In fact this is the getopt entry in the source: { "listen", no_argument, NULL, OPT_LISTEN + OO }, See that? That is "no argument". And why have you been telling me that "--listen ipaddress" and/or "listen=ipaddress" is possible? And exactly what openswan configuration are you using to test with?
Ignore the above comment. Looks like 'whack' has a --listen option without any argument.
Ok, now I can see a difference. Your testing procedure is just listening on UDP port 500. When I run vpnc on a different interface it isn't just listening on UDP port 500, it is an active bound instance. With UDP there are three types of bindings: IP:500<=>x:y, IP:500<=>*:*, and *:500<=>*:*. You have been testing assuming the second type whereas my situation is the first. That is, there is an active vpnc instance which is bound to a specific IP and port 500 with an active specific foreign address on one of the other interfaces. That is why the non-specific bind() in find_raw_ifaces4() fails. If vpnc was not running, and if I was using "nc -ul ..." instead, then the problem would not appear because the non-interface-specific bind() in find_raw_ifaces4() would work when the other process is performing just a listen(). Also, it doesn't matter whether one uses "--listen" or "--interface" because the find_raw_ifaces4() happens regardless of either of those two command-line options. So to simulate this problem you need to have nc actively bound rather than passively listening on the other interface.
Using two IKE daemons to manipulate the kernel SPD/SAD policies is wrong, as neither daemon will actually be in full sync with the existing kernel policies in the kernel. Possibly using namespaces this is possible, but than the bind would also be in a separate namespace, and should not interfere. Additionally, future versions of the pluto IKE daemon will dynamically bind when a new interface appears, such as when inserting a USB wifi/3G device. It will also listen on all UDP (4)500 IP addresses to pick up newly received IP addresses from DHCP. This is done to be more accomodating to devices that often change between interfaces (wifi/3g on phones for example) I believe the current behaviour of preventing two simultaneous IKE daemons from running on a host is correct.
Well the fact is that I cannot use openswan with the checkpoint hardware. So I use vpnc. And I use openswan for connections to Cisco. And the FACT is that my patch works for me and fixes the bug. Everything remains in full sync ALL OF THE TIME, because the kernel does not mix up things as you suggest it might. Different namespaces are NOT REQUIRED. So on the one hand you instruct me to use "--interface" and then you next tell me that future software versions are going to ignore any "--interface" option and bind to whatever interface pops up. That is exactly what you have just said! It is remarkable that you spent any time on this bug at all. Why didn't you simply close the bug as WONTFIX at the outset using the same flawed logic as you have finally come up with? Why wait until you are told that your test procedure is flawed before coming up with your lame WONTFIX response? This is absolutely the last time I will ever bother to report a bug via redhat bugzilla. Enough is enough. I can simply patch the software and continue. It seems pointless trying to make other users aware of any improvement to their software via redhat bugzilla.
I never told you to use --interfaces. I only told you to not use it, because it is KLIPS only and not relevant for XFRM/NETKEY. What is the problem with Checkpoint? Can you file a separate bug for that? The next version of libreswan (3.6) will have an interop fix for Checkpoint related to IKE padding. Perhaps that is your issue. You can try the patch: https://github.com/libreswan/libreswan/commit/ab763468da8d8f33d5c7ac3d7281f704d60aed7d and setting ikepad=no to see if that resolves your issue. You only told me in comment #10 that you were attempting to use two IKE daemons. Your goal of running two IKE daemons goes against the overal goals of *swan to be as flexible as possible with modern requirements of hosts that frequently change network devices and IP addresses. I would rather spend the time on figuring out the checkpoint interop issue, than add a workaround option to enable running two IKE daemons at once.
In my original comment I said this: > > 2. on another interface, eg eth1, run something with bind to isakmp port (eg. vpnc) > Your "... only told me in comment #10 ..." is a very myopic contribution on your part. Or maybe even an outright lie. You must have dug very deep to find that one. Pity you never started by looking at the initial bug report. In any case I need to use a Vasco key fob for the vpnc connection and vpnc makes that nice and easy. I have no evidence that Openswan allows one to easily enter the magic number when bringing up such an interface.
It should allow that using nm-openswan. or using ipsec auto --up connname on the commandline
Firstly I don't use NetworkManager in any form. It is too awful. Secondly, openswan has NEVER worked for me with Checkpoint. I am not going to be retrying openswan every time there is a new version. Vpnc works just fine so I use vpnc. None of this has anything to do with the bug report. The bug report is very clear and very specific. The solution is very clear too. There is absolutely no need to bind() to anything to invoke the ioctl's needed to discover interface information. It ironic that some of the code that follows the bind() actually skips the ioctl's for other interfaces when --interface is used. Because the bind() in effect cripples the effectiveness of that code. Life can be really very simple IF YOU ALLOW IT TO BE!
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.