-1

I use the following rules on the server:

sudo iptables -A INPUT -p udp --dport  500 -j ACCEPT
sudo iptables -A INPUT -p udp --dport 4500 -j ACCEPT
sudo iptables -A FORWARD --match policy --pol ipsec --dir in  --proto esp -s 10.0.2.0/24 -j ACCEPT
sudo iptables -A FORWARD --match policy --pol ipsec --dir out --proto esp -d 10.0.2.0/24 -j ACCEPT
sudo iptables -t nat -A POSTROUTING -s 10.0.2.0/24 -o eth0 -m policy --pol ipsec --dir out -j ACCEPT
sudo iptables -t nat -A POSTROUTING -s 10.0.2.0/24 -o eth0 -j MASQUERADE
sudo iptables -t mangle -A FORWARD --match policy --pol ipsec --dir in -s 10.0.2.0/24 -o eth0 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1361:1536 -j TCPMSS --set-mss 1360

What's the equivalent for the client?

sunknudsen
  • 581
  • 10
  • 26
  • How restrictive is the client's firewall configured? Because commonly any outbound traffic and related inbound traffic is allowed. – ecdsa May 16 '19 at 07:38
  • Very restricted as they are headless servers... only what’s needed in or out is allowed. Everything else is dropped. – sunknudsen May 16 '19 at 12:55

1 Answers1

3

I'm assuming related inbound traffic is allowed, for instance, with a rule like this:

# iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

If outbound traffic is generally blocked, you need to add rules to allow the following type of traffic, depending on the actual configuration:

  • IKE (UDP ports 500 and 4500, by default):

    # iptables -A OUTPUT -p udp --dport 500 -j ACCEPT
# iptables -A OUTPUT -p udp --dport 4500 -j ACCEPT

    You could limit this more e.g. make it specific to an interface (-o <name>) or a destination address (-d <ip>). The source ports could also be matched, but in some situations using arbitrary source ports (i.e. configure 0 as source port in the strongSwan configuration) might be preferred, or are even required (e.g. if a custom server port is used).

  • If CRLs must be downloaded, or the server certificate is verified via Online Certificate Status Protocol (OCSP), the appropriate TCP ports must also be allowed, for instance:

    # iptables -A OUTPUT -p tcp --dport 80 -d <CRL server IP> -j ACCEPT
# iptables -A OUTPUT -p tcp --dport <OCSP port> -d <OCSP server IP> -j ACCEPT

  • If the client is behind a NAT or UDP encapsulation is forced, the ESP traffic will be sent using IKE's NAT-T UDP port. Otherwise, ESP traffic has to be allowed explicitly:

    # iptables -A OUTPUT -p 50 -j ACCEPT

    Again, this could be restrained to a specific destination etc.

  • Additional rules will be required for the actual VPN traffic. This can either be done using strongSwan's default updown script, which automatically inserts rules for the negotiated traffic selectors, or with a global catch-all rule for traffic that matches any IPsec policy:

    # iptables -A OUTPUT -m policy --dir out --pol ipsec -j ACCEPT
ecdsa
  • 3,800
  • 12
  • 26
  • Thanks @ecdsa. That got things moving. Do you know why the client traffic isn’t routed through the VPN? Running `curl https://checkip.amazonaws.com` returns client public IP. Also, can’t SSH to client from server. Created a separate question for these issues here: https://serverfault.com/questions/968613/how-can-i-route-all-traffic-through-strongswan-vpn. – sunknudsen May 23 '19 at 18:38