Project

General

Profile

Actions

Bug #11190

closed

IPsec VTI outbound NAT to interface address not working (pfsense 2.4.5-p1)

Added by Kevin Mychal Ong over 4 years ago. Updated about 4 years ago.

Status:
Duplicate
Priority:
Normal
Assignee:
-
Category:
IPsec
Target version:
-
Start date:
12/27/2020
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.4.5-p1
Affected Architecture:
amd64

Description

I have the same exact problem as this post https://www.reddit.com/r/PFSENSE/comments/cegi8d/ipsec_vti_nat_in_244p3/ and I posted on the pfsense forum as well https://forum.netgate.com/topic/159252/ipsec-outbound-nat-to-interface-address-reply-traffic-destination-ip-not-being-translated-back-to-original-source-ip/2?_=1608536857656. But basically the summary of the problem is if you have two sites connected by a Routed VTI IPsec tunnel and create an outbound NAT rule on the local site to SNAT to the site's pfsense IPsec interface IP address when accessing a host on the remote end, you do get the return traffic back up to the local IPsec interface but somehow gets dropped and never reaches the source (doesn't use the outbound NAT table to translate back to the original source). This method is a known workaround of IPsec not supporting reply-to's but it is not working as well. There are a couple of people confirming that it is not working also but I'm not sure why as it was published as an official workaround.

Actions #1

Updated by Jim Pingle over 4 years ago

  • Status changed from New to Duplicate

It used to work at one time, if it doesn't work now, it's almost certainly the same root cause as #8686 so doesn't need its own issue. There are workarounds available on that issue.

Actions #2

Updated by Kevin Mychal Ong over 4 years ago

Jim Pingle wrote:

It used to work at one time, if it doesn't work now, it's almost certainly the same root cause as #8686 so doesn't need its own issue. There are workarounds available on that issue.

Are you referring to the workaround that breaks policy based routing? What does that specifically break, any rule that uses the ipsec interface as a gateway regardless of any interfaces that rule is applied on?

Actions #3

Updated by Jim Pingle over 4 years ago

It doesn't break policy routing. It breaks filtering of policy based IPsec tunnels (ones using tunnel mode, not VTI).

Actions #4

Updated by Kevin Mychal Ong over 4 years ago

Jim Pingle wrote:

It doesn't break policy routing. It breaks filtering of policy based IPsec tunnels (ones using tunnel mode, not VTI).

Ahh. I see what you're saying. So does that mean that since I'm using Routed VTI and don't use traditional policy-based IPsec anyway, then applying the workaround won't really affect me negatively, yes?

Actions #5

Updated by Jim Pingle over 4 years ago

Correct. Keep any further discussion on the forum, though.

Actions #6

Updated by Kevin Mychal Ong over 4 years ago

Jim Pingle wrote:

Correct. Keep any further discussion on the forum, though.

Thanks. I tried to apply the workaround but it's not working for me. It breaks things even further. Let me know if you have any advices or if I'm doing it incorrectly and let's continue our conversation here: https://forum.netgate.com/post/953770 if you don't mind.

Actions #7

Updated by Kevin Mychal Ong about 4 years ago

Kevin Mychal Ong wrote:

Jim Pingle wrote:

Correct. Keep any further discussion on the forum, though.

Thanks. I tried to apply the workaround but it's not working for me. It breaks things even further. Let me know if you have any advices or if I'm doing it incorrectly and let's continue our conversation here: https://forum.netgate.com/post/953770 if you don't mind.

Jim, do you have any more ideas here?

Actions

Also available in: Atom PDF