[strongSwan] One IPsec client talk to another through the SeGW ?
graham.hudspith at gmail.com
Fri Mar 4 15:27:56 CET 2011
We've solved the problem here. Actually, there never was a problem.
When first chatting to the people here, NO secure communication was
After your last message, I did a little digging and, as so often happens in
these cases, reality was a little different.
It seems that Hosts A and B were able to ping each other through their IPsec
tunnels via the SeGW. In fact, we can even ssh through the tunnels from Host
A to Host B.
What was NOT happening was reception of UDP traffic sent from Host A to a
specific port on Host B (and vice versa). Once I got them to adjust the
firewall on Host B to open the udp port, everything started working too.
They were confused by the fact that we had already added a firewall rule
allowing all UDP traffic from an IPsec tunnel. They did not realise that
such traffic is decrypted and then sent back through the firewall again,
thus needing the specific UDP port opening too.
Sorry to have wasted your time.
On 4 March 2011 12:48, Graham Hudspith <graham.hudspith at gmail.com> wrote:
> Thanks for that. Unfortunately, all of these abstract labels are making my
> head hurt. Let's try some real numbers.
> Host A and Host B have local IP addresses in the 192.16.50.xxx subnet.
> The SeGW has an unsecure IP address (i.e. on eth0) in the 172.16.xxx.xxx
> subnet and a secure IP address (i.e. on eth1) in the 172.17.xxx.xxx subnet.
> The SeGW is configured to hand out virtual IP addresses to Hosts A and B
> using the 10.15.xxx.xxx subnet.
> So, we want Host A to be able to talk to other entities in the
> 10.15.xxx.xxx subnet using IPsec (i.e. Host A <-> Host B via SeGW) and ALSO
> we want Host A and Host B to be able to talk to entities on the secure side
> of the SeGW (i.e. other servers on the 172.17.xxx.xxx subnet).
> So, currently, on the SeGW we have:
> conn a-b-gw
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users