I have been doing more reading, and I notice that "man enc" states:
"Packets destined to be IPsec processed are seen by the
filer/translation engine twice, both before and after being IPsec
processed. If a packet's translated address on the way back fails to
match an existing IPsec flow, from the translated address to the
original source address, it will be discarded by the filter. It is best
to avoid this situation where possible, though a flow may be explicitly
created to work around it."
It sounds like I can setup another flow to allow my rdr rule to work
with the enc0 traffic, but I'm not sure what this flow would look like.
Can anyone provide an example of the flow, or explain what the
redirected traffic looks like on the enc0 interface?
I worry that I will need a flow with 127.0.0.1 specified, and that may
not be possible on the remote end.
Thanks,
Cam
Cameron Schaus wrote:
Hello Misc,
I have an OpenBSD 4.4 firewall with some clients connecting via
IPSEC. Some clients have flows established to servers not on the
local LAN, and these clients are natted through the internet interface
to access these servers. It's a bit convoluted, but things work,
except of course for ftp.
I configured the ftp-proxy for clients on the local lan and openvpn
clients (tun0), but I cannot appear to use ftp-proxy with IPSEC
clients (enc0).
I want to use a line such as:
rdr on enc0 proto tcp from any to any port 21 -> 127.0.0.1 port 8021
When this is in place, IPSEC clients cannot even connect to the ftp
server. I suspect there are some problems with this approach, since
the man pages show matching with ipencap, but you can't do tcp port
redirects with only ip encapsulated matching.
I am at a bit of a loss here, and I'm wondering if there's anything I
can do to proxy the IPSEC ftp traffic, or if there are any other
options I have at this point.
Thanks,
Cam
