| Summary: | IPsec N2N traffic to remote peer is not routed through tunnel if leftsubnet is an openvpn network | ||
|---|---|---|---|
| Product: | IPFire | Reporter: | jkroepke <jkr> |
| Component: | --- | Assignee: | Assigned to nobody - feel free to grab it and work on it <nobody> |
| Status: | CLOSED NOTABUG | QA Contact: | |
| Severity: | Minor Usability | ||
| Priority: | Will affect almost no one | CC: | christian.keck, michael.tremer, peter.mueller |
| Version: | 2 | ||
| Hardware: | unspecified | ||
| OS: | Unspecified | ||
| Bug Depends on: | |||
| Bug Blocks: | 11618 | ||
|
Description
jkroepke
2019-06-14 18:08:49 UTC
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? |