Follow up from #12045 The /usr/local/bin/ipsec-interfaces script just looks on green, blue or orange interface if the leftsubnet is match and if yes a route is created. https://github.com/ipfire/ipfire-2.x/commit/d66433fca6323940ac217d7a0834a0b178d509eb#diff-73b29dd22c29ab6614902308e5c73fcfR137 If the leftsubnet is the openvpn subnet no route entry on table 220 is created and the traffic will not route via the ipsec tunnel. Clients from OpenVPN network can access resources behind the tunnel without any problems. conn Tunnel1 left=%defaultroute leftsubnet=172.30.0.0/24 leftfirewall=yes lefthostaccess=yes # ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: red0: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 06:20:76:29:83:3a brd ff:ff:ff:ff:ff:ff inet 10.124.4.144/24 brd 10.124.4.255 scope global red0 valid_lft forever preferred_lft forever 10: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100 link/none inet 172.30.0.1 peer 172.30.0.2/32 scope global tun0 valid_lft forever preferred_lft forever
Can you confirm that this works when you add the IP address of your tun0 interface?
First of all if I execute ip route add table 220 10.237.0.0/16 proto static dev red0 src 172.30.0.1 manually everything is working fine. Changing the line in /usr/local/bin/ipsec-interfaces from > for _address in ${GREEN_ADDRESS} ${BLUE_ADDRESS} ${ORANGE_ADDRESS}; do to > for _address in ${GREEN_ADDRESS} ${BLUE_ADDRESS} ${ORANGE_ADDRESS} "172.30.0.1"; do resolves this issue and the traffic from the gateway works fine. All tunnels offline: # ip route show table 220 All tunnels online: # ip route show table 220 10.20.0.0/19 dev red0 proto static scope link src 172.30.0.1 10.237.0.0/16 dev red0 proto static scope link src 172.30.0.1
So Using hostname -I like > for _address in $(hostname -I); do should resolve the issue.
Any news about this issue?
(In reply to jkroepke from comment #4) > Any news about this issue? No, otherwise they would have been posted here. Although I thought I commented on the proposed fix, but it looks like that I didn't. Running "hostname -I" might fix this problem, but is entirely undeterministic and therefore cannot be implemented. The IP addresses are being listed in the order of the interfaces (by ID) and that changes from reboot to reboot. Creating firewall rules is impossible then. There might also be any subnets in there that are not needed or wanted. So the solution I would propose is to read the OpenVPN/IPsec RW subnets from the configuration and just add them to the list.
I can reproduce this behaviour.
Hi Michael Tremer, you could also use the standard behavior of strongswan instead to deactive it and try to recover it with own bash scripts. It should fix a lot.
(In reply to jkroepke from comment #7) > you could also use the standard behavior of strongswan instead to deactive > it and try to recover it with own bash scripts. The scripts do not provide this functionality at all. > It should fix a lot. Are you hinting that there are other bugs, too? It is really not hard to read the OpenVPN configuration files and add the subnet(s) to that list so that the script can iterate over it.
> Are you hinting that there are other bugs, too? Yes. Replace a software default behavior with an own logic results always in a lot of bugs since no one can cover the whole logic unless tests are available. I can't see tests. > It is really not hard to read the OpenVPN configuration files and add the subnet(s) to that list so that the script can iterate over it. Thats is correct. But its just more code and more logic which might work right now but what happend * if you create a openvpn server while a ipsec tunnel is running? * if you change the network of a server while a ipsec tunnel is running? Additionally if someone start to refactor the openvpn part he should know he have to change something in a strongswan startup script. It's more then just a simple sed on the openvpn config file. If you disagree, I can provide this one liner as pull request.
(In reply to jkroepke from comment #9) > > Are you hinting that there are other bugs, too? > > Yes. Replace a software default behavior with an own logic results always in > a lot of bugs since no one can cover the whole logic unless tests are > available. The original scripts to not have support for this at all. > Thats is correct. But its just more code and more logic which might work > right now but what happend > > * if you create a openvpn server while a ipsec tunnel is running? IPsec can be reloaded then. > * if you change the network of a server while a ipsec tunnel is running? Again, you will have to reload the IPsec tunnels of course. Those interdependencies won't go away by calling "hostname -I". You are introducing only other problems. > Additionally if someone start to refactor the openvpn part he should know he > have to change something in a strongswan startup script. > > It's more then just a simple sed on the openvpn config file. > > If you disagree, I can provide this one liner as pull request. I would only accept my proposed solution based on what I know about this problem. As stated earlier, calling "hostname -I" is not deterministic.
@jkroepke: Why did you close this?