4

I have a Digital Ocean droplet (similar to an Amazon EC2 instance) running Ubuntu Server 12.04.3 x64 with both strongswan 5.1.1 (built from source) and squid 3.4.2 (also built from source) installed.

Both the strongswan VPN and squid proxy function just fine individually, with some minor iptables rule changes between testing, of course.

What I would like to do is be able to initiate the VPN connection from my computer/device and have the outgoing VPN traffic automatically route through the local squid proxy.

That is, the flow of traffic should look something like this:

Client -> VPN -> Proxy -> Internet

Unfortunately, I can't seem to figure out a good way to get this sort of connection to work. A friend pointed out that the Output chain of the NAT table in iptables may be my solution, suggesting a rule like this:

iptables -t nat -A OUTPUT -p tcp --dport 80 -j REDIRECT --to-port 3128

While it makes sense to me logically how this might work, it doesn't appear to be doing so. I don't see any packets following the rule (periodically checking the incoming/outgoing packet counts with a iptables-save command) as I attempt to load content while connected to the VPN.

Mind you, I'm no expert with iptables or linux, so please bear with me here if something I said (or something I say) is silly/dumb/obviously-the-damn-problem. ;)

I'm open to any suggestions about how to solve this, but removing a component isn't a solution. I need both the VPN and Proxy running like this. Changing versions of either component is also not ideal, although much more feasible.

I've provided both ipsec.conf and squid.conf, as well as my current iptables rule script.

P.S. If you notice, there's some stuff related to using RADIUS for authentication. Don't worry about it. It's not currently being used and shouldn't have any effect on this question.

iptables script:

iptables -F
iptables -t nat -F
iptables -t mangle -F

iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

export WAN=eth0
export vpnclients=10.100.0.0/255.255.0.0

# Allow access to our SSH server from the WAN
iptables -A INPUT -p TCP --dport ssh -i ${WAN} -j ACCEPT

# Add the rules for NAT
# iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3128
iptables -t nat -A OUTPUT -p tcp --dport 80 -j REDIRECT --to-port 3128
iptables -t nat -A POSTROUTING -o ${WAN} -j MASQUERADE

iptables-save

ipsec.conf:

config setup
ca ipsec
        cacert=ca.pem
        auto=add

conn %default
        ikelifetime=60m
        keylife=20m
        ike=aes256-sha1-modp1024!
        esp=aes256-sha1!
        leftcert=vpn-server.crt
        leftauth=pubkey
        rightsendcert=never
        leftsendcert=always
        eap_identity=%identity%
        leftfirewall=yes
        auto=add

conn ikev1
        keyexchange=ikev1
        rightauth=pubkey
        rightauth2=xauth
        rightsourceip=10.100.0.0/16
        right=%any
        rightid=%any
        rightdns=8.8.8.8,8.8.4.4
        leftsourceip=<my_server_ip>
        leftsubnet=0.0.0.0/1,128.0.0.0/1,::/1,8000::/1

conn ikev2
        keyexchange=ikev2
        rightsourceip=10.100.0.0/16
        right=%any
        rightid=%any
        rightauth=eap-radius

squid.conf:

#dummy name used
cache deny all
forwarded_for off

#for debugging, enable in production
strip_query_terms off

cache_effective_user proxy
cache_effective_group proxy
client_dst_passthru on
host_verify_strict off
http_port 3130 intercept
http_port 3128
https_port 3129 intercept ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/etc/dev/squid.pem

always_direct allow all
ssl_bump server-first all

# the following two options are unsafe and not always necessary:
sslproxy_cert_error allow all
sslproxy_flags DONT_VERIFY_PEER

# Change these to your local DNS servers
dns_nameservers 8.8.8.8 8.8.4.4
coredump_dir /var/cache/squid

http_access allow all
http_reply_access allow all
7
  • Very nicely asked. So good, in fact, that I thought this was an audit question when it came through the review que.
    – Jon
    Feb 5, 2014 at 1:27
  • Haha, well I'm thrilled to hear that! :) Feb 5, 2014 at 2:02
  • In my book, that would be --to-ports, with a final s Feb 5, 2014 at 7:35
  • Unfortunately, that doesn't seem to have helped, but thanks for the suggestion! Looking around, I see people using that flag with and without the trailing 's', so not sure which is correct. I seem to get the same packet counts (e.g. none or very few) regardless of which I use. Feb 5, 2014 at 18:08
  • Why do you have the PREROUTING chain commented out? I think that will work and not the OUTPUT chain. Also, I what happens if you try the 3130 port instead of 3128? So I would try iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3130
    – prateek61
    Dec 12, 2014 at 2:28

1 Answer 1

1

I had the exact same problem, and after almost 1 day, I could solve this problem. This solution is for anyone reading this in the future.

Target: Same as the OP I was trying to reach

Client -> VPN -> Proxy -> Internet

Setup: Ubuntu 16.04

VPN: L2TP using xl2tpd and pptpd, as well as strongswan for encryption The VPN setup and the Squid Proxy server are on the same machine.

Private IP Pool for handing out IPs to clients: 172.21.118.0/24

As the OP expected, you need to run -j REDIRECT --to-port 3128 on some nat table (either PREROUTING or OUTPUT).

Probing and logging around with the different tables, here is the path each packet originating from 172.21.118.0/24 follows:

mangle PREROUTING -> nat PREROUTING -> mangle FORWARD -> filter FORWARD -> mangle POSTROUTING -> nat POSTROUTING

I understood how this work, using a great illustration of the iptables packet lifecycle:

enter image description here Source: http://64-bit.de/dokumentationen/netzwerk/e/002/DE-IPTABLES-HOWTO-3.html

As it turned out, this setup does not send anything on the OUTPUT chain, so the only place to redirect a port is the PREROUTING chain.

The solution is simply:

iptables -t nat -I PREROUTING  -i ppp0 -s 172.21.118.1/24 -j REDIRECT --to-ports 3128

Also do not forget to SNAT to your public IP in order to reach the internet:

iptables -t nat -A POSTROUTING -j SNAT -s 172.21.118.2/24 --to-source ${IP} -o eth0
#Alternatively but slower:
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
1
  • unfortunately, I have same problem, the main goal was to block some domains for my vpn users, but i discovered that vpn redirect web traffic to proxy by website ip not by its domain. did you have any solution for this ?
    – Realbitt
    Dec 28, 2021 at 10:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .