Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 07 Aug 2020 19:14:39 +0000
From:      bugzilla-noreply@freebsd.org
To:        net@FreeBSD.org
Subject:   [Bug 248474] NAT broken on IPsec/VTI [if_ipsec]
Message-ID:  <bug-248474-7501-Mp6jrRMZAq@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-248474-7501@https.bugs.freebsd.org/bugzilla/>
References:  <bug-248474-7501@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D248474

Ziomalski <kokosmaps@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|Not A Bug                   |FIXED

--- Comment #23 from Ziomalski <kokosmaps@gmail.com> ---
(In reply to Michael Muenz from comment #22)
Thanks Michael for your comments/testing.=20

Can you expand a bit on mixing route/policy based connections? I actually
require one of each for my setup. My production is running on EdgeMax and t=
his
VTI/NAT issue was my last road-block to switching to pf/opn-sense, or so I
thought.

[VTI]
LAN(192.168../16) -> filtered dest. subnets -> VTI with NAT(10.../32)

[Policy]
LAN(192.168../16) -> Remote net(60.../29) -> Tunnel with NAT(193.../32)
Local-193.../32
Remote-60.../29

Both of these VPNs are only used one way. The far end does not connect to o=
ur
resources.

You have me worried with your statement and so any advice would be great. A=
re
you a dev for one of the sense? Should I move this to a forum?

I'm a bit under-experienced compared to you guys(especially with the backend
stuff) so I really appreciate the help.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-248474-7501-Mp6jrRMZAq>