1
17.7 Legacy Series / Re: Traffic inexplicably not going through IPSEC despite matching SPs
« on: November 06, 2017, 02:43:58 pm »
As I said, I don't have an opnsense instance running at the moment
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1]
2
17.7 Legacy Series / Re: Traffic inexplicably not going through IPSEC despite matching SPs
« on: November 06, 2017, 02:34:56 pm »
Hello xinnan.
I've posted on the pfSense forum as well, as I mentioned early on in the post above.
When you talk about a different underlying BSD, what do you mean? They should both be based upon FreeBSD 11. Are you talking about patches?
About the opnsense instance, I might be able to put one up, but I have a relatively complicated network infrastructure, so it could take time.
I've seen posts on the opnsense forums and github issues mentioning problems with NAT before IPSEC, so I was wondering whether my situation might be similar to those.
I've posted on the pfSense forum as well, as I mentioned early on in the post above.
When you talk about a different underlying BSD, what do you mean? They should both be based upon FreeBSD 11. Are you talking about patches?
About the opnsense instance, I might be able to put one up, but I have a relatively complicated network infrastructure, so it could take time.
I've seen posts on the opnsense forums and github issues mentioning problems with NAT before IPSEC, so I was wondering whether my situation might be similar to those.
3
17.7 Legacy Series / Traffic inexplicably not going through IPSEC despite matching SPs
« on: November 06, 2017, 12:02:56 pm »
Hello people.
Let me just say first that the problem I am having is with a recent version of pfSense, which of course is not the product discussed here. I have posted on that forum as well, but since I believe this to be an underlying issue I would like to understand whether it has been addressed by the OPNsense people instead. We are considering a migration, even though it's still only a thought at this point.
Feel free to pelter me with stones or to move the thread elsewhere should that be appropriate.
So, for the details:
I am running a pfSense 2.4.0 twin installation with CARP between the two appliances.
I have been able to successfully establish a transport mode IPSEC connection, using a CARP VIP, between the pfSense installation and an external Linux machine, both using strongSwan to handle the negotiation.
On top of the IPSEC connection I am running a GRE tunnel between the two endpoints.
One problem I've encountered is that I had to forcefully disable stateful inspection on the packets going through the gre0 interface, otherwise after a few tens of seconds packets started getting dropped by the default rules on pfSense, stalling and terminating connections.
That behaviour didn't arise if the GRE tunnel was established without an IPSEC layer underneath.
Something at least related to this issue here https://redmine.pfsense.org/issues/4479 I think.
Anyway that is not what's still bugging me.
Something else is quite strange.
Let's say that my CARP VIP, the pfSense endpoint of the transport mode IPSEC "tunnel", is 1.1.1.1, and the other endpoint is 2.2.2.2 .
So basically on my pfSense I have a security policy directing the traffic from 1.1.1.1 to 2.2.2.2 through IPSEC (the actual traffic is UDP-encapsulated, btw).
But if I try and ping 2.2.2.2 from a client behind my pfSense installation (ICMP traffic this going through outbound NAT and exiting the firewall having 1.1.1.1 as source address), this traffic does not go through IPSEC, as a traffic capture on the outside interface shows me.
The machine on the other side tries to send answer packets through IPSEC instead (I think).
So basically, ICMP traffic for 2.2.2.2 going through outbound NAT translating the source address to 1.1.1.1 doesn't go through IPSEC encapsulation even though, from what I understand, it should match the SP with those exact source and destination addresses.
I've read somewhere about a FreeBSD/StrongSwan problem related to performing NAT before IPSEC encapsulation but I am not sure whether it's relevant to my case or if it's out-of-date information.
I've tried to understand/debug the flow but I haven't found anything to help me sort out this situation.
On top of that I've found no decent way to trace the flow of the packets involved through the networking stack, although I will admit that I work mostly on Linux platforms and my knowledge of FreeBSD pales in comparison.
Can anyone help me understand this?
Thanks,
Fulvio
Let me just say first that the problem I am having is with a recent version of pfSense, which of course is not the product discussed here. I have posted on that forum as well, but since I believe this to be an underlying issue I would like to understand whether it has been addressed by the OPNsense people instead. We are considering a migration, even though it's still only a thought at this point.
Feel free to pelter me with stones or to move the thread elsewhere should that be appropriate.
So, for the details:
I am running a pfSense 2.4.0 twin installation with CARP between the two appliances.
I have been able to successfully establish a transport mode IPSEC connection, using a CARP VIP, between the pfSense installation and an external Linux machine, both using strongSwan to handle the negotiation.
On top of the IPSEC connection I am running a GRE tunnel between the two endpoints.
One problem I've encountered is that I had to forcefully disable stateful inspection on the packets going through the gre0 interface, otherwise after a few tens of seconds packets started getting dropped by the default rules on pfSense, stalling and terminating connections.
That behaviour didn't arise if the GRE tunnel was established without an IPSEC layer underneath.
Something at least related to this issue here https://redmine.pfsense.org/issues/4479 I think.
Anyway that is not what's still bugging me.
Something else is quite strange.
Let's say that my CARP VIP, the pfSense endpoint of the transport mode IPSEC "tunnel", is 1.1.1.1, and the other endpoint is 2.2.2.2 .
So basically on my pfSense I have a security policy directing the traffic from 1.1.1.1 to 2.2.2.2 through IPSEC (the actual traffic is UDP-encapsulated, btw).
But if I try and ping 2.2.2.2 from a client behind my pfSense installation (ICMP traffic this going through outbound NAT and exiting the firewall having 1.1.1.1 as source address), this traffic does not go through IPSEC, as a traffic capture on the outside interface shows me.
The machine on the other side tries to send answer packets through IPSEC instead (I think).
So basically, ICMP traffic for 2.2.2.2 going through outbound NAT translating the source address to 1.1.1.1 doesn't go through IPSEC encapsulation even though, from what I understand, it should match the SP with those exact source and destination addresses.
I've read somewhere about a FreeBSD/StrongSwan problem related to performing NAT before IPSEC encapsulation but I am not sure whether it's relevant to my case or if it's out-of-date information.
I've tried to understand/debug the flow but I haven't found anything to help me sort out this situation.
On top of that I've found no decent way to trace the flow of the packets involved through the networking stack, although I will admit that I work mostly on Linux platforms and my knowledge of FreeBSD pales in comparison.
Can anyone help me understand this?
Thanks,
Fulvio
Pages: [1]