After upgrading a custumers IP-Fire router to "IPFire 2.17 (i586) - Core Update 95" we were not able to connect to the red0 interface from any IP-Address belonging to a remote subnet defined in an IPSec connection. Investigating this error led me to the new iptables chain IPSECBLOCK rejecting all packets from any source ip (0.0.0.0/0) to the IPSec remote subnet. Our nagios monitoring system (ip address inside IPSec remote subnet) did'nt get any (icmp) responses from the exterior ip address of the IP-Fire router any more. Quick and dirty solution was to modify /usr/lib/firewall/ipsec-block to accept packets from red0 to IPSec remote subnet: :<------------------------------------------ VPN_CONFIG="/var/ipfire/vpn/config" LOCAL_IPADDRESS=`cat /var/ipfire/red/local-ipaddress` block_subnet() { local subnet="${1}" # Don't block a wildcard subnet if [ "${subnet}" = "0.0.0.0/0" ] || [ "${subnet}" = "0.0.0.0/0.0.0.0" ]; then return 0 fi # allow traffic from red0 to IPSec remote subnet(s)... iptables -A IPSECBLOCK -s "${LOCAL_IPADDRESS}" -d "${subnet}" -j ACCEPT iptables -A IPSECBLOCK -d "${subnet}" -j REJECT --reject-with icmp-net-unreachable } :<------------------------------------------ diff /usr/lib/firewall/ipsec-block-dist /usr/lib/firewall/ipsec-block-new 23a24,25 > LOCAL_IPADDRESS=`cat /var/ipfire/red/local-ipaddress` > 31a34,36 > # allow traffic from red0 to IPSec remote subnet(s)... > iptables -A IPSECBLOCK -s "${LOCAL_IPADDRESS}" -d "${subnet}" -j ACCEPT > 58a64 >
I do not really understand why this is an issue here. The IPSECBLOCK chain rejects traffic only if is is supposed to be sent out without being encrypted. Could you please provide more information about which packets hit the rule which actually should not?
Created attachment 400 [details] networ layout
Hi Micheal, thanks for your quick response! I've added a sketch of the network layout to this report, to clarity my explanations a little... In our (probably special) case we're using the IPsec tunnel for administration and backup purposes. Our company (left side of attached skech) uses provider-independent ip addresses, so our hosts can connect directly to other hosts on the internet. Normal internet traffic of our green subnet is routed through Main Firewall (upper left). Only traffic to the customer's green subnet is routed through IP-Fire (lower left) and encrypted on its way over the internet by IPsec. Our Nagios system monitors the internet connection of our customer via the red0 interface on his IP-Fire. This connection should work in spite of a tunneling problem between the two IP-Fire systems; also should connections to the customers IP-Fire GUI via "Incoming Firewall Access" to his red0 interface. In my opinion only the traffic between those subnets declared in an IPsec configuration (our and customer's green subnets) should be encrypted - and blocked if tunnel is down. Traffic to/from the exterior interfaces (red0) is not to be encrypted and therefore should not be blocked. (But outgoing traffic from customer's red0 to remote green subnet (our's) ips also is blocked by standard IPSECBLOCK rules) Hope this explanation helps to clarify... So long! Edgar
(In reply to Edgar Wiesmann from comment #3) > In my opinion only the traffic between those subnets declared in an IPsec > configuration (our and customer's green subnets) should be encrypted - and > blocked if tunnel is down. That is exactly what the IPSECBLOCK chain is doing here. > Traffic to/from the exterior interfaces (red0) is not to be encrypted and > therefore should not be blocked. (But outgoing traffic from customer's red0 > to remote green subnet (our's) ips also is blocked by standard IPSECBLOCK > rules) Could you please post the rules in that chain?
You're wlcome! Actual rules: Chain IPSECBLOCK (2 references) num target prot opt source destination 1 ACCEPT all -- 88.79.184.74 192.168.2.0/24 2 REJECT all -- 0.0.0.0/0 192.168.2.0/24 reject-with icmp-net-unreachable 3 ACCEPT all -- 88.79.184.74 193.99.nnn.0/24 4 REJECT all -- 0.0.0.0/0 193.99.nnn.0/24 reject-with icmp-net-unreachable rule 1 an 3 are inserted by my modifcation of /usr/lib/firewall/ipsec-bloc (see first posting) Original rules: Chain IPSECBLOCK (2 references) num target prot opt source destination 1 REJECT all -- 0.0.0.0/0 192.168.2.0/24 reject-with icmp-net-unreachable 2 REJECT all -- 0.0.0.0/0 193.99.nnn.0/24 reject-with icmp-net-unreachable
Could you also post the output of "ipsec statusall"?
[root@router-do ~]# ipsec statusall Status of IKE charon daemon (strongSwan 5.3.3, Linux 3.14.57-ipfire, i686): uptime: 28 days, since Dec 14 16:41:55 2015 malloc: sbrk 514512, mmap 0, used 272472, free 242040 worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 7 loaded plugins: charon aes des rc2 sha1 sha2 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl gcrypt fips-prf gmp xcbc cmac hmac ctr ccm gcm curl attr kernel-netlink resolve socket-default farp stroke updown eap-identity eap-mschapv2 eap-radius eap-tls eap-ttls eap-peap xauth-generic xauth-eap xauth-noauth dhcp Listening IP addresses: 192.168.10.1 192.168.1.1 88.79.184.74 10.208.44.1 Connections: do2du: tunnel.2motion.net...2mo-du.nsupdate.info IKEv2, dpddelay=30s do2du: local: [tunnel.2motion.net] uses pre-shared key authentication do2du: remote: [2mo-du.nsupdate.info] uses pre-shared key authentication do2du: child: 192.168.1.0/24 === 192.168.2.0/24 TUNNEL, dpdaction=restart 2mo2rif: tunnel.2motion.net...129.217.202.215 IKEv2, dpddelay=30s 2mo2rif: local: [tunnel.2motion.net] uses pre-shared key authentication 2mo2rif: remote: [129.217.202.215] uses pre-shared key authentication 2mo2rif: child: 192.168.1.0/24 === 193.99.163.0/24 TUNNEL, dpdaction=restart Security Associations (2 up, 0 connecting): do2du[570]: ESTABLISHED 30 minutes ago, 88.79.184.74[tunnel.2motion.net]...193.99.165.202[2mo-du.nsupdate.info] do2du[570]: IKEv2 SPIs: 66efe3a6a0225c59_i a6b94968a7e6e063_r*, pre-shared key reauthentication in 2 hours do2du[570]: IKE proposal: AES_GCM_16_256/PRF_HMAC_SHA2_512/MODP_4096 do2du{12403}: INSTALLED, TUNNEL, reqid 545, ESP SPIs: c38aa627_i c0a812ca_o, IPCOMP CPIs: 15f0_i d7d5_o do2du{12403}: AES_GCM_16_256, 0 bytes_i (0 pkts, 88s ago), 0 bytes_o, rekeying in 18 minutes do2du{12403}: 192.168.1.0/24 === 192.168.2.0/24 do2du{12404}: INSTALLED, TUNNEL, reqid 545, ESP SPIs: c52bd660_i c5bdf024_o, IPCOMP CPIs: eda1_i 5276_o do2du{12404}: AES_GCM_16_256, 0 bytes_i (0 pkts, 88s ago), 0 bytes_o, rekeying in 15 minutes do2du{12404}: 192.168.1.0/24 === 192.168.2.0/24 do2du{12405}: INSTALLED, TUNNEL, reqid 545, ESP SPIs: cbcba02f_i c5f8f7ed_o, IPCOMP CPIs: aa65_i a157_o do2du{12405}: AES_GCM_16_256, 0 bytes_i (0 pkts, 88s ago), 0 bytes_o, rekeying in 12 minutes do2du{12405}: 192.168.1.0/24 === 192.168.2.0/24 do2du{12406}: INSTALLED, TUNNEL, reqid 545, ESP SPIs: cf63f261_i c4730c99_o, IPCOMP CPIs: a554_i 6be6_o do2du{12406}: AES_GCM_16_256, 0 bytes_i (0 pkts, 88s ago), 0 bytes_o, rekeying in 16 minutes do2du{12406}: 192.168.1.0/24 === 192.168.2.0/24 do2du{12407}: INSTALLED, TUNNEL, reqid 545, ESP SPIs: c90eda60_i ceb271a4_o, IPCOMP CPIs: 9f0b_i 37ab_o do2du{12407}: AES_GCM_16_256, 0 bytes_i (0 pkts, 88s ago), 0 bytes_o, rekeying in 13 minutes do2du{12407}: 192.168.1.0/24 === 192.168.2.0/24 do2du{12408}: INSTALLED, TUNNEL, reqid 545, ESP SPIs: c676f322_i c655696c_o, IPCOMP CPIs: 6d64_i ba02_o do2du{12408}: AES_GCM_16_256, 262 bytes_i (2 pkts, 88s ago), 254 bytes_o (1 pkt, 27s ago), rekeying in 11 minutes do2du{12408}: 192.168.1.0/24 === 192.168.2.0/24 do2du{12409}: INSTALLED, TUNNEL, reqid 545, ESP SPIs: c89f4a41_i c69e7f21_o, IPCOMP CPIs: c806_i eb97_o do2du{12409}: AES_GCM_16_256, 0 bytes_i (0 pkts, 88s ago), 0 bytes_o, rekeying in 15 minutes do2du{12409}: 192.168.1.0/24 === 192.168.2.0/24 do2du{12410}: INSTALLED, TUNNEL, reqid 545, ESP SPIs: c2481ff3_i c1ffe7d0_o, IPCOMP CPIs: 0355_i a519_o do2du{12410}: AES_GCM_16_256, 0 bytes_i (0 pkts, 88s ago), 0 bytes_o, rekeying in 16 minutes do2du{12410}: 192.168.1.0/24 === 192.168.2.0/24 do2du{12411}: INSTALLED, TUNNEL, reqid 545, ESP SPIs: cb13e132_i ce9b4e4b_o, IPCOMP CPIs: e32e_i 4e52_o do2du{12411}: AES_GCM_16_256, 0 bytes_i (0 pkts, 88s ago), 0 bytes_o, rekeying in 14 minutes do2du{12411}: 192.168.1.0/24 === 192.168.2.0/24 do2du{12412}: INSTALLED, TUNNEL, reqid 545, ESP SPIs: c6fff27e_i c567b69b_o, IPCOMP CPIs: 8906_i 9790_o do2du{12412}: AES_GCM_16_256, 0 bytes_i (0 pkts, 88s ago), 0 bytes_o, rekeying in 18 minutes do2du{12412}: 192.168.1.0/24 === 192.168.2.0/24 do2du{12413}: INSTALLED, TUNNEL, reqid 545, ESP SPIs: c7c41216_i c2c95a97_o, IPCOMP CPIs: 1f2c_i 8374_o do2du{12413}: AES_GCM_16_256, 0 bytes_i (0 pkts, 88s ago), 0 bytes_o, rekeying in 15 minutes do2du{12413}: 192.168.1.0/24 === 192.168.2.0/24 do2du{12414}: INSTALLED, TUNNEL, reqid 545, ESP SPIs: c7197fc2_i c2dced58_o, IPCOMP CPIs: 3c86_i 0f52_o do2du{12414}: AES_GCM_16_256, 0 bytes_i (0 pkts, 88s ago), 0 bytes_o, rekeying in 20 minutes do2du{12414}: 192.168.1.0/24 === 192.168.2.0/24 do2du{12415}: INSTALLED, TUNNEL, reqid 545, ESP SPIs: c6c98aea_i c6db4453_o, IPCOMP CPIs: 2e77_i a934_o do2du{12415}: AES_GCM_16_256, 256288 bytes_i (782 pkts, 27s ago), 321153 bytes_o (807 pkts, 27s ago), rekeying in 14 minutes do2du{12415}: 192.168.1.0/24 === 192.168.2.0/24 2mo2rif[569]: ESTABLISHED 43 minutes ago, 88.79.184.74[tunnel.2motion.net]...129.217.202.215[129.217.202.215] 2mo2rif[569]: IKEv2 SPIs: 8a3e33bdfeb229ef_i* 3d97ebb5e6f14c8b_r, pre-shared key reauthentication in 111 minutes 2mo2rif[569]: IKE proposal: AES_GCM_16_256/PRF_HMAC_SHA2_512/MODP_4096 2mo2rif{12402}: INSTALLED, TUNNEL, reqid 544, ESP SPIs: c0ebbb3c_i ccf22b87_o, IPCOMP CPIs: 2c9a_i bd5d_o 2mo2rif{12402}: AES_GCM_16_256, 560915 bytes_i (8929 pkts, 10s ago), 1123376 bytes_o (8565 pkts, 10s ago), rekeying in 3 minutes 2mo2rif{12402}: 192.168.1.0/24 === 193.99.163.0/24 2mo2rif{12416}: INSTALLED, TUNNEL, reqid 544, ESP SPIs: c7df91bc_i ccf8ab07_o, IPCOMP CPIs: 2258_i b6e5_o 2mo2rif{12416}: AES_GCM_16_256, 3091 bytes_i (41 pkts, 1s ago), 6466 bytes_o (44 pkts, 0s ago), rekeying in 44 minutes 2mo2rif{12416}: 192.168.1.0/24 === 193.99.163.0/24
Is this bug still valid?
Unfortunately yes.
Is there any progress on this topic? Unfortunately this is a showstopper for us, we need to be able to route traffic between the different n2n-interfaces, not matter if they are OpenVPN or IPSec based. This always worked for us until this blocking implementation came up. IMHO there simply is a missing link: If we want to keep the current solution, IPFire should automatically add an exception to IPSECBLOCK for the regarding source networt when a firewall-rule is added with an IPSec-interface or network as target. As long as this is not implemented, it would be sufficient to know if this can be done by adding CUSTOM-rules - if that's possible at all. Thanks!
I would argue that something must have changed because of this: https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=d66433fca6323940ac217d7a0834a0b178d509eb Could someone please confirm that this is still a problem for you and include the route tables and iptables outputs?
Has this patch already been applied in Core 134? And if so, could it have been reverted by importing configs from an older backup?
This has been shipped with Core Update 129: > https://blog.ipfire.org/post/ipfire-2-21-core-update-129-released And no, this would always be applied as long as the update has been installed correctly.
Okay, then I can confirm that this issue still exists and the patch did not solve it.
In that instance I need a detailed assessment about what goes wrong. I am quite sure that this problem is not the same as the one this bug was opened for.
Okay, please tell me how I can help to get these informations.
(In reply to Christian Keck from comment #16) > Okay, please tell me how I can help to get these informations. Please attach the output of "iptables -L -nv", your IPsec configuration, and the output of "ip route" and "ip route show table 220" here.
Created attachment 706 [details] Dumps of IPTables, routes etc. as requested
I added the anonymized dumps as ZIP archive. Hopefully I did not scramble something while substituting with the placeholders. The file "pinging host in IPSec network" shows what happens when I (re-)enable the IPSECBLOCK chain. The ping was sent from the SSH-Shell of a remote IPFire connected via OpenVPN-tunnel. HTH
Here's a observation I made recently about the conditions that need to be met to trigger the bug: - One has set up more than one IPSec-connection - At least one of these connections is disabled (checkbox unchecked) As long as all connections are enabled, the problem does not occur. In that case also the blocking-chain "IPSECBLOCK" is empty in the IPTables. HTH
It seems that not only OpenVPN-traffic, but also h2n-traffic via RoadWarrior is affected by this bug: https://forum.ipfire.org/viewtopic.php?f=16&t=23474
Created attachment 717 [details] ipsec-policy with IPSECBLOCK ACCEPT rules for left subnets Only a idea for approach. Since all IPSEC specific iptable rules are handled by ipsec-policy, I decided to add missing rules for more than one left subnet to ipsec-policy. Its working in my roadwarrior scenario
(In reply to henning.ryll from comment #22) > Created attachment 717 [details] > ipsec-policy with IPSECBLOCK ACCEPT rules for left subnets > > Only a idea for approach. > Since all IPSEC specific iptable rules are handled by ipsec-policy, I > decided to add missing rules for more than one left subnet to ipsec-policy. > Its working in my roadwarrior scenario Henning, you really need to follow the rules on how to submit patches. It is great that you are working on this, but I cannot see what you have changed in this file and I am not going to spend more than 5 minutes to find out what it is. I also do not understand your comment either about what you want to solve here.
I'm not a developer and I did not know how to handle a developing environment. i.e. what is github or how to create a diff file you like. So my samples are not fixes. But I think it could be useful for a developer as idea, how to handle the error. There are many threads in the ipfire forum about malfunction of IPSEC since IPSECBLOCK was introduced. Some of these threads are linked in this bug too. The problem is described and discussed there in detail. Of course I can copy the whole thread an put it here as comment. But why? As described IPSECBLOCK blocks network traffic to a IPSEC network. But this was wrong in some cases! So the solution of most people running into this problem is to disable IPSECBLOCK oder use 0.0.0.0 as interface. Not a real good solution. All places I have found dealing with IPSECBLOCK is ipsec-policy file. Since there are rules missing to allow network traffic to IPSEC I think the right place is this file to correct the error. And in my sample I did it for me. Don't know if there is another place to handle this problem. And don't know if it fixes the net2net problem too. But I know, that IPSECBLOCK is working wrong as it is since it's introduction long ago. So I think that a developer who has knowledge in routing and pearl should have a look.
(In reply to henning.ryll from comment #24) > I'm not a developer and I did not know how to handle a developing > environment. i.e. what is github or how to create a diff file you like. > So my samples are not fixes. But I think it could be useful for a developer > as idea, how to handle the error. That is not a problem. We have some detailed documentation about how to do this and there is a development mailing list where you can ask questions: > https://wiki.ipfire.org/devel/submit-patches > There are many threads in the ipfire forum about malfunction of IPSEC since > IPSECBLOCK was introduced. Some of these threads are linked in this bug too. > The problem is described and discussed there in detail. > Of course I can copy the whole thread an put it here as comment. But why? > > As described IPSECBLOCK blocks network traffic to a IPSEC network. But this > was wrong in some cases! > So the solution of most people running into this problem is to disable > IPSECBLOCK oder use 0.0.0.0 as interface. > Not a real good solution. You do not say at all what the problem was and how you were aiming to fix this. How can someone peer review this now and see if your patch does what you intend? > All places I have found dealing with IPSECBLOCK is ipsec-policy file. Since > there are rules missing to allow network traffic to IPSEC I think the right > place is this file to correct the error. What error? > And in my sample I did it for me. Don't know if there is another place to > handle this problem. And don't know if it fixes the net2net problem too. > But I know, that IPSECBLOCK is working wrong as it is since it's > introduction long ago. What is working wrong? > So I think that a developer who has knowledge in routing and pearl should > have a look. So you do not have confidence that this solution does not introduce any new problems?
(In reply to Michael Tremer from comment #25) > What error? > What is working wrong? I think the malfunction is well described here and the the related topics in the forum: As soon as at least one of the IPSec-tunnels is deactivated, all trafic between IPSec-interfaces and other VPN-networks is dropped. If you disable the IPSECBLOCK-rules it works again.
(In reply to Christian Keck from comment #26) > (In reply to Michael Tremer from comment #25) > > What error? > > What is working wrong? > > I think the malfunction is well described here and the the related topics in > the forum: As soon as at least one of the IPSec-tunnels is deactivated, all > trafic between IPSec-interfaces and other VPN-networks is dropped. If you > disable the IPSECBLOCK-rules it works again. No, this is absolutely not clear here. People are talking about at least three different problems. The solution that Henning has offered is adding a NAT rules that translates everything that goes through the tunnel to the IP address of the GREEN network that belongs to the firewall. I have no idea what that is meant to solve. I think it is absolutely okay to ask what he tried to do here.
Michael, I agree with you that blindly adding NATting rules for all interfaces is at least a questionable solution since one has no overview over these "holes" from the WUI. I also wouldn't double this solution as SNAT is not always needed nor wanted. But at least the fact that traffic between different VPN-interfaces does not work with IPSECBLOCK when *any* of the IPSec-tunnels is deactivated still stands. AFAIC it must be connected with the invocation of "install_policy()" in "/usr/lib/firewall/ipsec-policy", but I have not yet figured out from which script this function is called. Maybe the solution lies in checking the "if clause" that causes the function to block a specific subnet.
Looks, as there are at least 2 (net2net / roadwarrior2net) problems with subproblems. 1.) As far as I understood, to establish a communication from OVPN to IPSEC a additional NAT rule is necessary in both cases 2.) If "IPSECBLOCK reject" rule exists, no communication is possible via OVPN to IPSEC site. If "IPSECBLOCK reject" rule is removed by hand, a communication to IPSEC site is established immediatly. If the local/left net was set to 0.0.0.0 the script 'ipsec-policy' did not add a "IPSECBLOCK reject" rule. Because of this, the effect is the same as removing the rule by hand. From the users point of view everything works fine (If he has added the NAT rule) The problem that is described by Christian works the same way. IPSECBLOCK reject rejects all traffic from OVPN to IPSEC. And of course establishing a connection from a machine in the green network to a remote machine via IPSEC is working all the times without any modification. But that is a complete other use case. Since the ipsec-policy script removes all IPSECBLOCK rules (and more) it is not a good idea to build additional rules by hand. So the idea of Christian was, to loosen the "IPSECBLOCK reject" by adding some "accept" rules, before the final "reject". This is done in my sample script if a second left net is registered (problem 2). In addition I have added the NAT rules (problem 1). By doing this 2 things no manual intervention is necessary if IPSEC is startet or stopped. Since I did not have a net2net environment I can't test impact thereon. But I hope that the net2net problem is blown away too. I'm using the script for a week now in my production environment. Rebooting ipfire, restart OVPN, restart IPSEC, broken connections. No more problems so far.
(In reply to henning.ryll from comment #29) > Looks, as there are at least 2 (net2net / roadwarrior2net) problems with > subproblems. > 1.) > As far as I understood, to establish a communication from OVPN to IPSEC a > additional NAT rule is necessary in both cases > 2.) > If "IPSECBLOCK reject" rule exists, no communication is possible via OVPN to > IPSEC site. If "IPSECBLOCK reject" rule is removed by hand, a communication > to IPSEC site is established immediatly. > > If the local/left net was set to 0.0.0.0 the script 'ipsec-policy' did not > add a "IPSECBLOCK reject" rule. Because of this, the effect is the same as > removing the rule by hand. From the users point of view everything works > fine (If he has added the NAT rule) > > The problem that is described by Christian works the same way. IPSECBLOCK > reject rejects all traffic from OVPN to IPSEC. Yes, this is exactly what the chain is supposed to be doing and that is working well. If you want to have access from OpenVPN to IPsec, you will have to add the subnets to the routed subnets of that VPN tunnel. The script will then add a rule and you will have routes installed for the communication to work. There is no SNAT required and you should not be using NAT here. It is a workaround, but ultimately you are having a misconfiguration here. > Since the ipsec-policy script removes all IPSECBLOCK rules (and more) it is > not a good idea to build additional rules by hand. I would argue that that is never a good idea. We have reasons why we solve things the way we do. > So the idea of Christian was, to loosen the "IPSECBLOCK reject" by adding > some "accept" rules, before the final "reject". There is nothing that should be accepted here. The clue is also in the name. The purpose of this chain is that no packet that is destined for a VPN is breaking out unencrypted on RED when the tunnel is not up - for any reason. It is a security measure which would be entirely useless when we would add ACCEPT rules here. > This is done in my sample script if a second left net is registered (problem > 2). In addition I have added the NAT rules (problem 1). Adding those rules removes the security here. You could have just removed the whole chain. > By doing this 2 things no manual intervention is necessary if IPSEC is > startet or stopped. And that will break existing setups. We build VPNs so that we can route data packets from one network to another one over the Internet. You remove the subnet part of it and change it so that only firewall A talks to firewall B. Since you do not see any packets with their original source IP address any more you cannot build firewall rules based on those. > Since I did not have a net2net environment I can't test impact thereon. How did you build this then when you do not have a VPN? > But I hope that the net2net problem is blown away too. > I'm using the script for a week now in my production environment. > Rebooting ipfire, restart OVPN, restart IPSEC, broken connections. No more > problems so far. That might all be the case, but you removed the security that you are getting from this, too. Thank you for this detailed explanation, but we should have talked about this before you sit down and write that script to save you the time.
Sorry, I overlooked this comment... (In reply to Christian Keck from comment #28) > Michael, I agree with you that blindly adding NATting rules for all > interfaces is at least a questionable solution since one has no overview > over these "holes" from the WUI. I also wouldn't double this solution as > SNAT is not always needed nor wanted. As I stated above, this is not only "a little bit ugly". It is a non-solution that works around the actual problem. > But at least the fact that traffic between different VPN-interfaces does not > work with IPSECBLOCK when *any* of the IPSec-tunnels is deactivated still > stands. Yes. But that is another problem than what was reported initially and you should create an extra bug. Please include the content of the IPSECBLOCK chain when all connections are enabled and one is disabled.