+-------+ Client 1 |
    +--------------+             +---------------+         +----------+           +------------+        |       +----------+
    |  Web Server  +-------------+ Cisco ASA5585 +---------+ Internet +-----------+ StrongSwan +--------+       IP:
    +--------------+             +---------------+         +----------+           +------------+        |
                                                                                                        |       +----------+
                                                                                                        +-------+ Client 2 |
   Internal Web server          External IP:                           External IP:             +----------+
   https://some.webservice.net                                                 Internal IP:            IP:
  • Clients 1 and 2 are in different /20 subnets and need to access the internal web server on the remote side through the host to host IPSEC VPN tunnel between the StrongSwan server and a remote Cisco ASA device.

  • We don't have any control over the remote side.

  • We have routing in place to allow client 1 and client 2 to reach the StrongSwan server.

  • We have the tunnel established between the StrongSwan server and the Cisco ASA device.

  • We have IP forwarding enabled on the StrongSwan server.

I'm trying to find out whether its feasible to use iptunnel to masquerade clients 1 and 2 as the StrongSwan server itself in order to allow them to access the internal web server at the remote side of the tunnel.

2 Answers 2


Easy way to make connections to Webserver come form StrongSwan machine will be to install a proxy like squid and use it from the clients instead of directly connecting to the Webserver.

Depending on what type of resources Clients want to access on Webserver, a fullblown squid might be overkill. If it's only port 443, and you don't need port 443 on StronSwan for other purposes, you can use redirect option of xinetd on StrongSwan. This will make etc/hosts entries in your Clients necessary, otherwise Webserver's certificate would be rejected for obvious name mismatch. There are other TCP proxies than xinetd redirect, but you get the idea.


You can do this with iptables configured on the StrongSwan box.

iptables -t nat -A POSTROUTING -s -o eth0 -m policy --dir out --pol ipsec -j ACCEPT
iptables -t nat -A POSTROUTING -s -o eth0 -j MASQUERADE

assuming eth0 is your egress ether (ethernet to the internet)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.