OpenVPN route command bug

Virtual Private Networks
1

I had some trouble getting Windows to properly IP forward, but once I had that working, I found this issue was preventing my site-to-site OpenVPN VPN from allowing packets to route properly. On IPFire, here is the log:

16:13:25 openvpnserver[29843]: AldenNJ/100.35.242.165:62671 MULTI: Learn: 192.168.27.100 -> AldenNJ/100.35.242. 165:62671
16:04:44 openvpnserver[29843]: AldenNJ/100.35.242.165:62671 MULTI: Learn: 192.168.27.100 -> AldenNJ/100.35.242. 165:62671
16:01:58 openvpnserver[29843]: AldenNJ/100.35.242.165:62671 MULTI: Learn: 192.168.27.100 -> AldenNJ/100.35.242. 165:62671
15:58:46 openvpnserver[29843]: AldenNJ/100.35.242.165:62671 MULTI: Learn: 192.168.27.100 -> AldenNJ/100.35.242. 165:62671
15:57:56 openvpnserver[23463]: /sbin/ip addr del dev tun1 local 10.165.5.1 peer 10.165.5.2
15:57:56 openvpnserver[23463]: Closing TUN/TAP interface
15:57:56 openvpnserver[23463]: /sbin/ip route del 192.168.27.0/24
15:57:56 openvpnserver[23463]: Exiting due to fatal error
15:57:56 openvpnserver[23463]: TCP/UDP: Socket bind failed on local address [AF_INET][undef]:1194: Address alre ady in use (errno=98)
15:57:56 openvpnserver[23463]: Socket Buffers: R=[163840->163840] S=[163840->163840]
15:57:56 openvpnserver[23463]: Could not determine IPv4/IPv6 protocol. Using AF_INET
15:57:56 openvpnserver[23463]: Data Channel MTU parms [ L:1522 D:1450 EF:122 EB:389 ET:0 EL:3 ]
15:57:56 openvpnserver[23463]: ERROR: Linux route add command failed: external program exited with error status : 2
15:57:56 openvpnserver[23463]: /sbin/ip route add 10.165.5.0/24 via 10.165.5.2
15:57:56 openvpnserver[23463]: /sbin/ip route add 192.168.27.0/24 via 10.165.5.2
15:57:56 openvpnserver[23463]: /sbin/ip addr add dev tun1 local 10.165.5.1 peer 10.165.5.2
15:57:56 openvpnserver[23463]: /sbin/ip link set dev tun1 up mtu 1400
15:57:56 openvpnserver[23463]: do_ifconfig, tt->did_ifconfig_ipv6_setup=0
15:57:56 openvpnserver[23463]: TUN/TAP TX queue length set to 100
15:57:56 openvpnserver[23463]: TUN/TAP device tun1 opened
15:57:56 openvpnserver[23463]: ROUTE_GATEWAY 71.162.200.1/255.255.255.0 IFACE=red0 HWADDR=d8:eb:97:69:3b:b7

This instance of IPFire is running core 144 on 32-bit version. Note the route command failure. For now, I just entered a static route to work around it and all is well, but anyone who might better understand this who wants to help debug it, please contact me and I can provide ANY and ALL logs you need to resolve this.

Thanks!

2

Hi atechguy,
the more interesting part in my opinion is →

port 1194 is already in use, it seems that another service uses this port. You wrote about Side-to-Side, this log is from the server (Point-to-Side), both topologies needs to have different ports, if you have it that way running you may have another service listening on port 1194 ?

Best,

Erik

3

Hi,

This instance of IPFire is running core 144 on 32-bit version.

please consider moving to 64-bit instead. 32-bit installations are considered insecure.

Just a footnote: Please report bugs at https://bugzilla.ipfire.org/ ; the wiki describes how to do this. :slight_smile:

Thanks, and best regards,
Peter Müller

4

Just to clarify, it’s site-to-site. The log above is for the IPFire.

The IPFire is also running an IPSec VPN to another IPFIre router to connect another network. Is this configuration not supported?

There is only ONE OpenVPN configuration defined on the IPFire in question and presumably, that VPN would be the one using port 1194. The OpenVPN service has been stopped and restarted several times (mostly changing the log Verb level) so perhaps when stopping the OpenVPN service, it doesn’t close the port?

5

Thanks Peter, I was looking for the link for the bug reporting. We can close this thread and I will open it up on the bugzilla site. My only issue is that I can’t find anywhere on the bugzilla site, the place where I can create a login! It’s not letting me login using my community login. The wiki explains about HOW to write a bug report, but not how to create an account on bugzilla to enter one! :slight_smile:

Oh, and if you ask about looking at the documentation, I did create the creating an account, where it suggests going to the NEW link in the header, but when I get to the “New” page, it simply wants me to login, and there is no place where I can create a new login.

6

You do not have to create another account for this as your login credentials will work there as well.

7

That’s the problem! It’s not working as well. And, then if I ask it to reset password, it never sends me a link. Something is seriously broken. Sorry to be a pain.

8

please write a massage to @ms

9

mmh then you have a modified configuration cause N2N (or side-to-side) does have an n2n in the logging section, ‘openvpnserver’ is always the OpenVPN server or Roadwarrior except you´d modified it.

Also, no routing problems here…

Best,

Erik

10

Of course, we’re all trying to address a bug here and the best course usually would be to include CONF and log files, but I would prefer to do that in the bugzilla section if I could log in there.

11

Not sure I can until I have some number of posts… Despite using IPFire for over five years, I haven’t spent much time in the community, but really wanted to post my experience doing site-to-site with OpenVPN from Windows to IPFire if it can help others.

12

Howzit Ken

Erik is correct. This doesn’t look like a bug, but a misconfiguration. Looking at your snipped, this is where your problem starts.

TCP/UDP: Socket bind failed on local address [AF_INET][undef]:1194: Address alre ady in use (errno=98)

Everything thereafter is a direct result of not being able to establish a connection correctly.

By default OVPN runs on UDP/1194. This is also the port used for Roadwarriors.
I have a few sites with single or multiple N2N OpenVPN configurations.
The N2N will need to have additional ports assigned to it, you cannot use UDP/1194, this will cause issues. Assign anything you like, recommend is to stick with UDP it’s faster, but there is nothing that can stop you from going TCP if you feel you must.
Use a port not in use by anything else on your networks (server and client side). Don’t use UDP/500 or UDP/4500 if you are also running IPSEC (default ports), use TCP/500 or TCP/4500 instead if you want to keep the numbers.
Better yet, check what ports are in use by which service and where it’s pointing to.

lsof -i -P -n | grep LISTEN
Should let you know what is open currently.

Also remember that both VPN sides cannot have the same IP range. If side A is 192.168.27.0/24 then side B needs to be something else, i.e. 192.168.28.0/24.

I hope this helps you along. Cheers

13

Humm, I don’t think that’s the issue I’m having. At least it doesn’t have that issue. the VPN connects brilliantly. It’s the ROUTE that doesn’t get entered. Thus, the other endpoint of the VPN is able to ping the IPFire end, and, it’s even able to ping machines on the IPFire (green) LAN. Where my problem was happening, was when a pc on the remote lan was trying to reach a pc on the IPFire LAN. In that case, because the route wasn’t entered, my packets would enter the VPN from the remote side, but then get dropped on the IPFire side because the SOURCE address wasn’t from the OpenVPN network, IPFire could drop it onto the LAN, but not have a proper route to return it to the sender (in say, ICMP)

So, you see, the way we’re using the IPFire, is to use a road-warrior (OpenVPN) VPN from a node in the remote network, which is acting as a router to the IPfire network. This remote node needs to use the ISP router (long story) so we couldn’t replace it with an IPFire and use normal site-to-site IPSec as we’re doing in another remote network.

14

You guys have been great so, and since I am waiting to get into bugzilla, let me post the log file from the IPFire so you can see the “Whole story”.

I put it up on my public folder in dropbox:

15

Ok, indulge me and fill in the missing gaps so I can see if I have this correctly.

Boss LAN - 192.168.27.0/24
	|
Big Boss VPN - 10.165.5.0/24 on port?
Boss FW static IP or DDNS ?
	|
	|
Internet, magic cloud and stuff... here be dragons!
	|
	|
Remote Router static IP or DDNS ?
	|
Remote FW 71.162.200.1/24 ? Is this correct?
Remote VPN - What IP range and on port?
	|
Remote LAN - 192.168.10.0/24

Where does 100.35.242.165 fall into the picture, and who’s DNS is 192.168.13.1?

Is that the route of the traffic we are talking about?

What would be missing would be the two FW rule entries that would permit both VPN to talk to each others LAN. I’m assuming your FW policies are set to block, and you need to open whatever needs to be allowed.
You would also need to ensure that IPS/IDS knows not to block either sites IPs by accident, if you have not done so already.
For example a forward rule, that says remote LAN can talk to Big Boss FW (no clue what it is so will take 100.35.242.165 as the example) via UDP/5000 which is the N2N port.

Chain FORWARDFW (1 references)
 pkts bytes target     prot opt in     out     source               destination  
    0     0 LOG        udp  --  *      *       192.168.10.0/24     100.35.242.165       udp dpt:5000 limit: avg 10/sec burst 20 LOG flags 0 level 4 prefix "FORWARDFW "
    0     0 ACCEPT     udp  --  *      *       192.168.10.0/24     100.35.242.165       udp dpt:5000
    0     0 ACCEPT     all  --  green0 *       192.168.27.0/24     192.168.10.0/24    
    0     0 ACCEPT     all  --  *      *       10.165.5.0/24        192.168.10.0/24    
    0     0 ACCEPT     all  --  *      *       192.168.10.0/24     10.165.5.0/24       



Chain OUTGOINGFW (1 references)
 pkts bytes target     prot opt in     out     source               destination      
    0     0 LOG        udp  --  *      *       REMOTE_FW_IP       192.168.10.0/24     udp dpt:5000 limit: avg 10/sec burst 20 LOG flags 0 level 4 prefix "OUTGOINGFW "
    0     0 ACCEPT     udp  --  *      *       REMOTE_FW_IP       192.168.10.0/24     udp dpt:5000

I would need to have a look tomorrow and see how I actually created the FW rule entries and take a screenshot, because i may have just confused myself with this explanation… or its just late and my bed is calling.
Btw being behind a router should not be a problem as long as the FW ends up with a routable IP on red0. I’ve done a few N2N setup via ADSL, and it worked, provided the DDNS resolved for both sites, before the VPN is connected, or else you would manually have to restart the service both sides.

I hope this helps you a bit further. Need to go sleep. Will check tomorrow if I can find the correct rules, if you need them.

Cheers.

16

All super questions.

OK, let’s start at the “center”. That’s the IPFire we’re addressing in this thread. It’s located at 71.162.200.69 (red) and 192.168.13.1 (green). the Open VPN Tunnel network is 10.165.5/24 with 10.165.5.5-6 being at the remote host (client Openvpn) and 10.165.5.1-2 being held by the IPFire.

The remote LAN in question (relevant to this thread) is 192.168.13.0/24. It’s a windows server with IP-routing enabled, lan IP is 192.168.27.103, and the Tun/Tap interface at 10.165.5.6

The 192.168.10/0 is confusing, and I apologize. It’s there because the IPFire we’re talking about also has an IPSec site-to-site VPN with another IPFire that has green0 set to 192.168.10.1/24.

Three networks, sadly not all routed by IPFire, but two are, and they are connected with IPSec (non-roadwarrior) and the third with OpenVPN. (192.168.27/24)

The 100.35.242.165 is the WAN IP of the remote (roadwarrior/OpenVPN) network, 192.168.27.0/24

That DNS @192.168.13.1 was only set by the roadwarrior/OpenVPN config so that users on that remote lan wanting to reach 192.168.13.0/24 hosts by name could query that IPFire DNS server. It really isn’t required.

So, IPS /Firewall rules aside, what do you think is causing the external call to ROUTE to FAIL? Regardless of what firewall rules this IPFIre might have, I fail to see how that might affect the setting of the ROUTES to 192.168.27.0/24.

Before I get to the other parts, hopefully the above will clarify the situation/networks. Also please excuse my syntax, on the VPN, but I think of the two options one has with IPFire is either (typically) a site-to-site (non NATable) IPSec option, OR, the Road-warrior OpenVPN solution. In our case, we’re pushing the OpenVPN solution to make it site-to-site by pushing routes to the client (the .27.0/24) and by setting the default gateway in that LAN to point to 192.168.13.0/24 by pointing other hosts to 192.168.27.103 and allowing windows to route into the OpenVPN network.

I wish I were a better artist to draw this out, but I think of it pretty simply in that the 192.168.27.0/24 network is not a single-router network and that it has the default route via 10.35.242.165 (the ISP router) and another route for 192.168.13.0/24 to be found via this windows server @ .103 which terminates the OpenVPN VPN on 10.165.5.6.

All this thread is about is the failure of the IPFire to SET the route back to 192.168.27.0/24. Everything else is working peachy. My work-around was to set a STATIC ROUTE for that network (despite listing it on the OpenVPN config) and that seems to work. My reasoning for creating this thread was so that others who may not be quite a well versed in routing, might realize that if they are configuring an OpenVPN (roadwarrior) VPN to be used for site-to-site, that if they see this error in their logs, that (for now) the solution is to set the static route.

I hope that makes sense to everyone.
Thanks again for your inputs