How to allow an ipsec tunnel endpoint to communicate with an internal IP on the other side?

Hi,

My setup is like this: There are two sites. The internal network on one
site
is 192.168.0.0/24 and the other side is 192.168.1.0/24. There is an
ipsec
server (let's call them r001 and r002 respectively) on each site
establishing
a VPN tunnel. Of course both r001 and r002 have a public IP. The VPN is
working
fine for the computers on the internal networks.

However, the question is, how to allow r001 itself connect to a host on

192.168.1.0/24 (eg, ping, ssh)? In most cases r001 will pick its public
IP
(because that interface is on the way to the default gateway). This
causes a
problem because a public IP can't connect to a private IP.

How to solve this problem? Thanks in advance!

kent@cpttm.org.mo wrote:
> Hi,
>
> My setup is like this: There are two sites. The internal network on one
> site
> is 192.168.0.0/24 and the other side is 192.168.1.0/24. There is an
> ipsec
> server (let's call them r001 and r002 respectively) on each site
> establishing
> a VPN tunnel. Of course both r001 and r002 have a public IP. The VPN is
> working
> fine for the computers on the internal networks.
>
> However, the question is, how to allow r001 itself connect to a host on
>
> 192.168.1.0/24 (eg, ping, ssh)? In most cases r001 will pick its public
> IP
> (because that interface is on the way to the default gateway). This
> causes a
> problem because a public IP can't connect to a private IP.
>
> How to solve this problem? Thanks in advance!

What's a VPN? The KAME port's IPSec (ipsec-tools+26sec)? OpenVPN?
OpenS/WAN+KLIPS? Some other combination?

If the VPN is working correctly, r001 should tunnel any traffic through
the VPN, on the public interface. I'm assuming the traffic is emitted,
but not moving through the VPN? Have you verified this? (Please note
that with at least the one VPN implementation I have used, a localhost
tcpdump will see stuff that isn't on the wire, because decrypted packets
are re-submitted to the network stack.)

Joachim

Joachim Schipper wrote:
> kent@cpttm.org.mo wrote:

>>In most cases r001 will pick its public IP
>>(because that interface is on the way to the default gateway). This
>>causes a
>>problem because a public IP can't connect to a private IP.
>>
>>How to solve this problem? Thanks in advance!
>
>
> What's a VPN? The KAME port's IPSec (ipsec-tools+26sec)? OpenVPN?
> OpenS/WAN+KLIPS? Some other combination?
>
> If the VPN is working correctly, r001 should tunnel any traffic through
> the VPN, on the public interface. I'm assuming the traffic is emitted,
> but not moving through the VPN? Have you verified this? (Please note
> that with at least the one VPN implementation I have used, a localhost
> tcpdump will see stuff that isn't on the wire, because decrypted packets
> are re-submitted to the network stack.)
>
> Joachim

If I remember what happens correctly, the FW knows to route packets down the tunnel correctly, but it uses the ip address of it's external interface since the traffic isn't being routed out the internal interface. The packet travels out the VPN tunnel, but since it's return address probably isn't part of the left_subnet (or whatever side it is), it doesn't route back correctly, or is blocked by firewall rules.

Add a rule to your iptables that tells the firewall to address its packets to the other lan using it's internal address rather than it's external one. Be very explicit in the packets you re-address this way, or you could end up messing up your regular outbound traffic.


iptables -t nat -A POSTROUTING -o ipsec0 -s $ext_ip -d $other_lan_subnet -j SNAT --to $int_ip

You may or may not need to add rules to actually allow this traffic depending on your config, but this should get you started.
bryan


--
If it isn't broke, fix it until it is.

Bryan Packer wrote:
> Add a rule to your iptables that tells the firewall to address its packets to
> the other lan using it's internal address rather than it's external one. Be
> very explicit in the packets you re-address this way, or you could end up
> messing up your regular outbound traffic.
>
>
> iptables -t nat -A POSTROUTING -o ipsec0 -s $ext_ip -d $other_lan_subnet -j
> SNAT --to $int_ip

Thanks. Does it mean that SNAT will be performed after ipsec tunneling?
So, the traffic is not encrypted?

kent@cpttm.org.mo wrote:
> Bryan Packer wrote:
>
>>Add a rule to your iptables that tells the firewall to address its packets to
>>the other lan using it's internal address rather than it's external one. Be
>>very explicit in the packets you re-address this way, or you could end up
>>messing up your regular outbound traffic.
>>
>>
>>iptables -t nat -A POSTROUTING -o ipsec0 -s $ext_ip -d $other_lan_subnet -j
>>SNAT --to $int_ip
>
>
> Thanks. Does it mean that SNAT will be performed after ipsec tunneling?
> So, the traffic is not encrypted?
>

Nope. The -o ipsec0 option only SNAT's packets leaving via the IPSec tunnel. The
encrypted packets that contain the SNAT'd packets would be leaving via eth1, and
won't be affected.

bryan