[Openswan Users] SNAT before IPSec, save my soul.
pupilla at hotmail.com
Fri Mar 24 17:13:24 CET 2006
Adrian R. Sanchez wrote:
>Can you see what the problem is? I can't get 192.168.0.4 to act like
>184.108.40.206 before getting into the IPSec tunnel through 220.127.116.11
This was a problem for linux kernel < 2.6.16rc
>Now that I have a 2.6.16 kernel + iptables 1.3.5... will a simple command
>iptables -t nat -A POSTROUTING -s 192.168.0.4 -d 18.104.22.168 -j SNAT --to
>...actually SNAT the packets before they enter the tunnel in the same box?
Yes. Did you try?
>Or do I need to issue a more specific syntax for a rule to do this?
You could also use the new 'policy match' to match packet that are
subject to ipsec processing. It give you the same functionality as
>From man iptables:
This modules matches the policy used by IPsec for
handling a packet.
Used to select whether to match the policy
used for decapsulation or the policy that
will be used for encapsulation. in is
valid in the PREROUTING, INPUT and FORWARD
chains, out is valid in the POSTROUTING,
OUTPUT and FORWARD chains.
Matches if the packet is subject to IPsec
Selects whether to match the exact policy
or match if any rule of the policy matches
the given policy.
Matches the reqid of the policy rule. The
reqid can be specified with setkey(8)
using unique:id as level.
Matches the SPI of the SA.
Matches the encapsulation protocol.
Matches the encapsulation mode.
Matches the source end-point address of a
tunnel mode SA. Only valid with --mode
Matches the destination end-point address
of a tunnel mode SA. Only valid with
--next Start the next element in the policy spec-
ification. Can only be used with --strict
More information about the Users