(In reply to johannes.huchler from comment #0)
> I think there is a problem with the new rejecting rule für ipsec connections

And what would this be? Do you actually get the connection reset by the local firewall?

Hy,

i need the SNAT. I have already set SNAT as set before the upgrade but i still not able to connect to the 10.0.0.0/8 network from the IPFire B Side. All connections on IPFire B are still working.

And i have testet the connection from OpenVPN Client over IPFire A to the 10.0.0.0/8 network and i can´t reach any network.

I have send a tracert and become the error Destination Net unreachable from the IPFire A. I think a gateway / nat problem should normaly be a ping timeout error. So i think the ping packed was rejected from the IPFire A

Is it possible to remove this new vpn reject rules for a test? Can you give me the iptables command to remove this?

Thank you!

(In reply to johannes.huchler from comment #2)
> Hy,
> 
> i need the SNAT. I have already set SNAT as set before the upgrade but i
> still not able to connect to the 10.0.0.0/8 network from the IPFire B Side.
> All connections on IPFire B are still working.
> 
> And i have testet the connection from OpenVPN Client over IPFire A to the
> 10.0.0.0/8 network and i can´t reach any network.
> 
> I have send a tracert and become the error Destination Net unreachable from
> the IPFire A. I think a gateway / nat problem should normaly be a ping
> timeout error. So i think the ping packed was rejected from the IPFire A
> 
> Is it possible to remove this new vpn reject rules for a test? Can you give
> me the iptables command to remove this?
> 
> Thank you!

Sorry, i mean "All connections on IPFire A are still working."

(In reply to johannes.huchler from comment #2)
> Hy,
> 
> i need the SNAT. I have already set SNAT as set before the upgrade but i
> still not able to connect to the 10.0.0.0/8 network from the IPFire B Side.
> All connections on IPFire B are still working.

I am still not quite sure what you are trying to achieve here. It seems that this should have not worked in the first place.

We have tightened the security of the IPsec rules a bit and this should not affect valid traffic at all, but your packets don't seem to be allowed in the IPsec policy any way.

> And i have testet the connection from OpenVPN Client over IPFire A to the
> 10.0.0.0/8 network and i can´t reach any network.
> 
> I have send a tracert and become the error Destination Net unreachable from
> the IPFire A. I think a gateway / nat problem should normaly be a ping
> timeout error. So i think the ping packed was rejected from the IPFire A

If you would create a SNAT rule on the web GUI, select the OpenVPN network where your RW client is in as source, the IPsec network you want to connect to as destination, enable SNAT and pick an IP address of the firewall which is in the IPsec policy (i.e. the local network), this should all be working fine I believe.

Can you confirm that you have set this up that way?

> Is it possible to remove this new vpn reject rules for a test? Can you give
> me the iptables command to remove this?

You could flush the block chain, but it would re-populate quite often. However, iptables -F IPSECBLOCK

(In reply to Michael Tremer from comment #4)
> (In reply to johannes.huchler from comment #2)
> > Hy,
> > 
> > i need the SNAT. I have already set SNAT as set before the upgrade but i
> > still not able to connect to the 10.0.0.0/8 network from the IPFire B Side.
> > All connections on IPFire B are still working.
> 
> I am still not quite sure what you are trying to achieve here. It seems that
> this should have not worked in the first place.
> 
> We have tightened the security of the IPsec rules a bit and this should not
> affect valid traffic at all, but your packets don't seem to be allowed in
> the IPsec policy any way.
> 
> > And i have testet the connection from OpenVPN Client over IPFire A to the
> > 10.0.0.0/8 network and i can´t reach any network.
> > 
> > I have send a tracert and become the error Destination Net unreachable from
> > the IPFire A. I think a gateway / nat problem should normaly be a ping
> > timeout error. So i think the ping packed was rejected from the IPFire A
> 
> If you would create a SNAT rule on the web GUI, select the OpenVPN network
> where your RW client is in as source, the IPsec network you want to connect
> to as destination, enable SNAT and pick an IP address of the firewall which
> is in the IPsec policy (i.e. the local network), this should all be working
> fine I believe.
> 
> Can you confirm that you have set this up that way?
> 
> > Is it possible to remove this new vpn reject rules for a test? Can you give
> > me the iptables command to remove this?
> 
> You could flush the block chain, but it would re-populate quite often.
> However, iptables -F IPSECBLOCK

Okay, i have flush the block chain and now i still able to reach some devices on the 10.0.0.0/8 network

The SNAT is configured as you describe but i think a other rule are in higher priority, so i'am not able to reach or configure a another rule.

I use the follwing connections:

IPFIRE A

IPSEC 1 to 10.0.0.0/8 network
IPSEC 2 to 192.168.20.0/24 network on IPFIRE B

IPFIRE B

IPSEC 1 to 192.168.202.0/24,10.0.0.0/8 network on IPFIRE A
network 192.168.202.0/24 is reachable but not the 10.0.0.0/8 network on the other IPSEC, same problem from the OpenVPN Clients to 10.0.0.0/8

Here you can see that my PING request is blocked by this rule from the openvpn network to the IPSEC 10.0.0.0/8 network. All networks are reachable after flush of the IPSECBLOCK rule.

Chain IPSECBLOCK (2 references)
pkts	bytes	target	prot	opt	in	out	source	destination	
140	8400	REJECT	all	--	*	*	0.0.0.0/0	10.0.0.0/8	reject-with icmp-net-unreachable

My SNAT rule (set via GUI):
pkts	bytes	target	prot	opt	in	out	source	destination	
0	0	LOG	all	--	*	*	192.168.252.0/24	10.0.0.0/8	limit: avg 10/min burst 20 LOG flags 0 level 4 prefix "SNAT "
0	0	SNAT	all	--	*	*	192.168.252.0/24	10.0.0.0/8	to:192.168.202.10

I have still no idea what firewall is dropping what packets and why that should be related to using SNAT at all.

Could you please provide more information in a way that is reproducible? Including which firewall is sending rejects to what system and from what origin the echo request is sent; if something is received on the other end; and if the reply is coming through the VPN.

The IPFire A blocks my traffic and drop all Traffic from the VPNs to the 10.0.0.0/8 network.

After i flush iptables with "iptables -F IPSECBLOCK" all connections works lika charm. But after a reconnect from any ipsec the network 10.0.0.0/8 is not reachable before i flush the table again. 

IPSECBLOCK on IPFire A (Block traffic from IPFIRE B 192.168.20.0/24 an 192.168.252.0/24 network to 10.0.0.0/8)
Chain IPSECBLOCK (2 references)
pkts	bytes	target	prot	opt	in	out	source	destination	
3	148	REJECT	all	--	*	*	0.0.0.0/0	10.0.0.0/8	reject-with icmp-net-unreachable
14	1676	REJECT	all	--	*	*	0.0.0.0/0	192.168.20.0/24	reject-with icmp-net-unreachable

SNAT on IPFire A
Chain NAT_SOURCE (1 references)
pkts	bytes	target	prot	opt	in	out	source	destination	
34	2000	LOG	all	--	*	*	192.168.20.0/24	10.0.0.0/8	limit: avg 10/min burst 20 LOG flags 0 level 4 prefix "SNAT "
34	2000	SNAT	all	--	*	*	192.168.20.0/24	10.0.0.0/8	to:192.168.202.10
0	0	LOG	all	--	*	*	192.168.252.0/24	10.0.0.0/8	limit: avg 10/min burst 20 LOG flags 0 level 4 prefix "SNAT "
0	0	SNAT	all	--	*	*	192.168.252.0/24	10.0.0.0/8	to:192.168.202.10

IPSECBLOCK on IPFIRE B
Chain IPSECBLOCK (2 references)
pkts	bytes	target	prot	opt	in	out	source	destination	
3	120	REJECT	all	--	*	*	0.0.0.0/0	192.168.202.0/24	reject-with icmp-net-unreachable
0	0	REJECT	all	--	*	*	0.0.0.0/0	10.0.0.0/8	reject-with icmp-net-unreachable

You are repeating the same information over and over again. That does not help me in any way.

This chain only rejects packets that are supposed to be routed to be sent through the VPN, but are actually not. The IPsec connection may not be established. I still don't know if this is happening on the source firewall or destination firewall. You are also not stating in what direction your echo request is sent. One can read that in both ways.

(In reply to Michael Tremer from comment #9)
> You are repeating the same information over and over again. That does not
> help me in any way.
> 
> This chain only rejects packets that are supposed to be routed to be sent
> through the VPN, but are actually not. The IPsec connection may not be
> established. I still don't know if this is happening on the source firewall
> or destination firewall. You are also not stating in what direction your
> echo request is sent. One can read that in both ways.

I have no problems from the 192.168.202.0/24 network on IPFire A. IPFire A managed the primary vpn connection to the 10.0.0.0/8 network. I think its a problem with SNAT and with the new block rules but u have no idea why. Is it possible to deactivate this rule for my configuration?

tracert from IPFire B network (192.168.20.0/24), all IPSec connections are up and running. 

tracert -d 10.122.216.1
Routenverfolgung zu 10.122.216.1 über maximal 30 Hops

  1    <1 ms    <1 ms    <1 ms  192.168.20.1
  2   191 ms    90 ms   158 ms  192.168.202.10
  3  192.168.202.10  meldet: Zielnetz nicht erreichbar.

After i flush ipsec block rules

tracert -d 10.122.216.1
Routenverfolgung zu 10.122.216.1 über maximal 30 Hops

  1    <1 ms    <1 ms    <1 ms  192.168.20.1
  2    73 ms    71 ms   111 ms  192.168.202.10
  3   129 ms   129 ms   133 ms  10.138.10.65
  4     *        *        *     Zeitüberschreitung der Anforderung.
  5   138 ms   220 ms   263 ms  10.123.0.218
  6   131 ms   181 ms   172 ms  10.123.0.194
  7   129 ms   172 ms   183 ms  10.122.32.4
  8     *        *        *     Zeitüberschreitung der Anforderung.
  9   213 ms   151 ms   248 ms  10.122.216.1

Ablaufverfolgung beendet.

Now i have removed the SNAT rules and have the same problem. The IPSECBLOCK rules blocks / rejects all traffic from external client networks that are not direct in the local subnet on IPFire A (192.168.202.0/24)

I am experiencing a similar issue after upgrading to the Core 95 update
Only difference on my setup is that it is a Host-to-Net Virtual Private Network (RoadWarrior)

In my case the user is dialing in and getting a 172.17.0.x IP address from OpenVPN.

My IPFire is set up with 5xIPSEC connections between branches:
 * 10.0.0.0/16
 * 10.163.200.0/23
 * 10.163.202.0/23
 * 10.190.0.0/16
 * 10.83.0.0/16

IPFire IP range is 10.91.0.0/16
OpenVPN range is 172.17.0.0/24 as mentioned

After the Core 95 version update my OpenVPN clients cannot work until the command 
iptables -F IPSECBLOCK is run

The client can ping 10.91.0.1 and any other IP's on my local IPFire.

The client cannot reach 10.163.x range (or any other) as it states Destination Net unreachable, although I have SNAT rules set which worked before.
Noting is being denied in firewall logs at all.

Any new news?

We need a solution for this issue.

Is it possible to create it as an option in the firewall settings, so we can activate or deactive this rule?

Thank you!

(In reply to johannes.huchler from comment #13)
> Any new news?

No, not from me.

> We need a solution for this issue.
> 
> Is it possible to create it as an option in the firewall settings, so we can
> activate or deactive this rule?

I do not think that there is a point having this configurable by the user. At least not as long as I don't understand fully what exactly is causing your problem here.

(In reply to Michael Tremer from comment #14)
> (In reply to johannes.huchler from comment #13)
> > Any new news?
> 
> No, not from me.
> 
> > We need a solution for this issue.
> > 
> > Is it possible to create it as an option in the firewall settings, so we can
> > activate or deactive this rule?
> 
> I do not think that there is a point having this configurable by the user.
> At least not as long as I don't understand fully what exactly is causing
> your problem here.

We use the IPFire as an internal VPN Gateway, so both devices red0 and green0 are in the same network behind a router. In fact access to the IPSec Networks is only possible from the local green0 network and not from the other VPNs. So i see you habe no solution for this problem. How we can remove this rule on every upgrade to prevent this issue?

I will test the rule with new settings for the source network:
iptables -A IPSECBLOCK -s 192.168.202/24 -d 10.0.0.0/8 -j REJECT --reject-with icmp-net-unreachable
iptables -A IPSECBLOCK -s 192.168.202/24 -d 192.168.20.0/24 -j REJECT --reject-with icmp-net-unreachable

I think thats the best solution. Is this okay for you? Can you implement this? I think the blocking rule has the same effect, because this is usually then on each IPFire system that is connectec via IPSec VPN.

(In reply to johannes.huchler from comment #15)
> (In reply to Michael Tremer from comment #14)
> > (In reply to johannes.huchler from comment #13)
> > > Any new news?
> > 
> > No, not from me.
> > 
> > > We need a solution for this issue.
> > > 
> > > Is it possible to create it as an option in the firewall settings, so we can
> > > activate or deactive this rule?
> > 
> > I do not think that there is a point having this configurable by the user.
> > At least not as long as I don't understand fully what exactly is causing
> > your problem here.
> 
> We use the IPFire as an internal VPN Gateway, so both devices red0 and
> green0 are in the same network behind a router. In fact access to the IPSec
> Networks is only possible from the local green0 network and not from the
> other VPNs. So i see you habe no solution for this problem. How we can
> remove this rule on every upgrade to prevent this issue?
> 
> I will test the rule with new settings for the source network:
> iptables -A IPSECBLOCK -s 192.168.202/24 -d 10.0.0.0/8 -j REJECT
> --reject-with icmp-net-unreachable
> iptables -A IPSECBLOCK -s 192.168.202/24 -d 192.168.20.0/24 -j REJECT
> --reject-with icmp-net-unreachable
> 
> I think thats the best solution. Is this okay for you? Can you implement
> this? I think the blocking rule has the same effect, because this is usually
> then on each IPFire system that is connectec via IPSec VPN.

Okay with the local network as source works all, can you please implement this?

(In reply to johannes.huchler from comment #15)
> We use the IPFire as an internal VPN Gateway, so both devices red0 and
> green0 are in the same network behind a router. In fact access to the IPSec
> Networks is only possible from the local green0 network and not from the
> other VPNs. So i see you habe no solution for this problem. How we can
> remove this rule on every upgrade to prevent this issue?

This is bad network design and you are tricking the routing logic to do things that might work for the moment, but actually some behaviour of that should be undefined. So effects like these are no surprise. The packets are not flowing into the direction as they are meant to. That *will* have severe security implications.

> I will test the rule with new settings for the source network:
> iptables -A IPSECBLOCK -s 192.168.202/24 -d 10.0.0.0/8 -j REJECT
> --reject-with icmp-net-unreachable
> iptables -A IPSECBLOCK -s 192.168.202/24 -d 192.168.20.0/24 -j REJECT
> --reject-with icmp-net-unreachable
> 
> I think thats the best solution. Is this okay for you? Can you implement
> this? I think the blocking rule has the same effect, because this is usually
> then on each IPFire system that is connectec via IPSec VPN.

This solution will however not work if you are using more than one local subnet (you can enter these comma-seperated). The result of that will be something like:

  iptables -A IPSECBLOCK -s a.b.c.d/e -d v.w.x.y/z -j REJECT ...
  iptables -A IPSECBLOCK -s f.g.h.i/j -d v.w.x.y/z -j REJECT ....

In that case,if rule one does not match, rule two will; or vice-versa.

Do you have any explanation *why* this (and no other solution) fixes this problem?

Closing this bug (last update 1.5y ago). If it is still valid, please reopen.