[strongSwan] Strongswan - IPSEC Gateway - Firewalling Troubles

Tue Jun 11 15:17:05 CEST 2013

Noel,

Thank you for this.

I am trying the rules for segregating the traffic and not sure i understand how this is working (or in my case isn't).

So before i set the default policy on the FORWARD chain to DROP i can reach my backend resources, say via a URL https://sharepoint.domain.com.

I now set the following:

IPTABLES -P FORWARD DROP
iptables -A FORWARD -s 10.0.50.0/24 -d 10.0.50.0/24 -j ACCEPT
iptables -A FORWARD -s 10.0.60.0/24 -d 10.0.60.0./24 -j ACCEPT

https://sharepoint.domain.com resolves to 172.17.81.128/28 subnet and should be allowed if connected to GROUP1.

However i cant access the resources. 

Do i have the -s and -d correct? 

So the client in this case is connected with a virtual IP address of 10.0.50.1/24 - which is the pool configured for Group 1.

Any help would be much appreciated.

Regards,

Andy Paton
________________________________________
From: Noel Kuntze [noel at familie-kuntze.de]
Sent: 10 June 2013 13:53
To: Paton, Andy
Subject: Re: [strongSwan] Strongswan - IPSEC Gateway - Firewalling Troubles

Hello Andy,
Answers:
1) You can insert filters to drop packages from group1 to the subnet of
group2 and to other ressources group1 shouldn't access based on the IP
you gave clients of group 1.
# All packages not exactly destined for the own host are going through
the forward chain, so firewalling has to be done here, not in the INPUT
chain.
# note that for these rules to function, the policy of the FORWARD chain
has to be set to DROP or REJECT.
iptables -A FORWARD -s 10.0.50.0/24 -d 10.0.50.0/24 -j ACCEPT
iptables -A FORWARD -s 10.0.60.0/24 -d 10.0.60.0./24 -j ACCEPT

2) You can set the policy of the input chain to drop and punch holes in
the firewall for the IKE protocols ah and esp which are used by IKE and
the corresponding ports for udp encapsulation.
Commands

# Set default policies
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
# allow communcation over the loopback interface
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# enable conntracking (used to track the connection states of inbound
and outbound connections
iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# some holes in the firewall for IKE
iptables -A INPUT -p ah -d 10.1.0.2 -j ACCEPT
iptables -A INPUT -p esp -d 10.1.0.2 -j ACCEPT
iptables -A OUTPUT -p ah -s 10.1.0.2 -j ACCEPT
iptables -A OUTPUT -p esp -s 10.1.0.2 -j ACCEPT
# hole for UDP encapsulation (used to pierce nat firewalls)
iptables -A INPUT -p udp --dport 500 -d 10.1.0.2 -j ACCEPT
iptables -A OUTPUT -p udp --sport 500 -s 10.1.0.2 -j ACCEPT
# MOBIKE
iptables -A INPUT -p udp --dport 4500 -d 10.1.0.2 -j ACCEPT
iptables -A OUTPUT -p udp --sport 4500 -s 10.1.0.2 -j ACCEPT
# Put more stuff for your management protocols like ssh, rpc or whatever
here
# like this:
# ssh:
# iptables -A INPUT -p tcp --dport 22 -d 10.1.0.2 -j ACCEPT
# allow outbound connections and packets answering connection attemps to
clients
iptables -A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

3) The best implementation for these scripts would be a simple service
file based on the system your distribution uses.
In Debian, I use an init script with cases (start,stop,restart,status)
to load it. On systemd based distributions I'd use a unit-file with a
corresponding entry to the script.
The reason for this is, that the rules only need to be inserted when the
system starts and not every time a client connects.

Regards,
Noel

PS: I do not guarantee, that those commands are error free! You should
read the manpage for iptables and then build your own commands!
(It's not difficult.)

Am 10.06.2013 14:08, schrieb Paton, Andy:
>
> All,
>
> I am currently – (struggling) – to work out how to best achieve an
> outcome to the following scenario, and would appreciate any help you
> could provide.
>
> *Scenario*
>
> 1.RoadWarrior IPSEC IKEv2 VPN Gateway
>
> 2.Routing to multiple backends, based on certificates
>
> *Current Setup*
>
> I have Strongswan running on a Ubuntu Server VM – with 3 Virtual NIC’s
> currently attached.
>
> -eth0 Public Facing Interface 10.1.0.2
>
> -eth1 Internal NIC Subnet ID 172.17.81.137/27
>
> -eth2 Internal NIC Subnet ID 162.17.81.137/27
>
> Users should be able to access only the relevant backend subnet for
> their role, and this is achieved using Wildcards in the certificates,
> and multiple configuration groups in SS.
>
> conn group1
> left=10.1.0.2
> leftcert=vpnserver.crt
> leftsubnet=172.17.81.128/27
> leftid=vpnserver.of.our.company.fqdn
> leftfirewall=yes
> right=%any
> rightid="DC=de, DC=company, O=Companyname, OU=group1 certificate, CN=*"
> rightsourceip=10.0.50.0/24
> auto=add
>
> conn group2
> left=10.1.0.2
> leftcert=vpnserver.crt
> leftsubnet=162.17.81.128/27
>
> leftid=vpnserver.of.our.company.fqdn
> leftfirewall=yes
> right=%any
> rightid="DC=de, DC=company, O=Companyname, OU=group2 certificate, CN=*"
> rightsourceip=10.0.60.0/24
>
> The idea here is that users in Group 2 shouldn’t be able to access the
> Subnet’s defined in Group 1.
>
> This configuration works in so much that IKEv2 connections are
> established and resources can be accessed from both zones.
>
> *However….*Currently the IPTABLES rules are wide open, so I can cross
> access resources.
>
> So my question is (and please bear in mind I am not an expert in
> IPTABLES / Firewalling):
>
> 1)How do I go about configuring the IPTABLES firewall such that only
> devices connected to group1 can access group1 subnets, and the same
> for group2.
>
> 2)How do I secure the front facing IP address of the gateway such that
> only IKE connections are allowed in?
>
> 3)What is the best way to implement these IPTABLES scripts?
>
> Also – I may need some help with the routing so for information..
>
> 1)Default GW on the 172.x.x.x subnet = 172.17.81.138
>
> 2)Default GW on the 162.x.x.x subnet = 162,17,81.138
>
> Regards,
>
> *Andy Paton
> *Business Development Solution Architect
>
> HP <http://www.hp.com/>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users