FreeS/WAN and firewalls

FreeS/WAN, or other IPsec implementations, frequently run on gateway machines, the same machines running firewall or packet filtering code. This document discusses the relation between the two.

The firewall code in 2.4 and later kernels is called Netfilter. The user-space utility to manage a firwewall is iptables(8). See the netfilter/iptables web site for details.

Filtering rules for IPsec packets

The basic constraint is that an IPsec gateway must have packet filters that allow IPsec packets, at least when talking to other IPsec gateways:

Your gateway and the other IPsec gateways it communicates with must be able to exchange these packets for IPsec to work. Firewall rules must allow UDP 500 and at least one of AHor ESP on the interface that communicates with the other gateway.

For nearly all FreeS/WAN applications, you must allow UDP port 500 and the ESP protocol.

There are two ways to set this up:

easier but less flexible
Just set up your firewall scripts at boot time to allow IPsec packets to and from your gateway. Let FreeS/WAN reject any bogus packets.
more work, giving you more precise control
Have the ipsec_pluto(8) daemon call scripts to adjust firewall rules dynamically as required. This is done by naming the scripts in the ipsec.conf(5) variables prepluto=, postpluto=, leftupdown= and rightupdown=.

Both methods are described in more detail below.

Firewall configuration at boot

It is possible to set up both firewalling and IPsec with appropriate scripts at boot and then not use leftupdown= and rightupdown=, or use them only for simple up and down operations.

Basically, the technique is

Since Pluto authenticates its partners during the negotiation, and KLIPS drops packets for which no tunnel has been negotiated, this may be all you need.

A simple set of rules

In simple cases, you need only a few rules, as in this example:

# allow IPsec
#
# IKE negotiations
iptables -A INPUT  -p udp --sport 500 --dport 500 -j ACCEPT
iptables -A OUTPUT -p udp --sport 500 --dport 500 -j ACCEPT
# ESP encrypton and authentication
iptables -A INPUT  -p 50 -j ACCEPT
iptables -A OUTPUT -p 50 -j ACCEPT
# uncomment for AH authentication header
# iptables -A INPUT  -p 51 -j ACCEPT
# iptables -A OUTPUT -p 51 -j ACCEPT

Other rules

You can add aditional rules, or modify existing ones, to work with IPsec and with your network and policies. We give a some examples in this section.

However, while it is certainly possible to create an elaborate set of rules yourself (please let us know via the mailing list if you do), it may be both easier and more secure to use a set which has already been published and tested.

The published rule sets we know of are described in the next section.

Adding additional rules

If necessary, you can add additional rules to:
reject IPsec packets that are not to or from known gateways
This possibility is discussed in more detail later
allow systems behind your gateway to build IPsec tunnels that pass through the gateway
This possibility is discussed in more detail later
filter incoming packets emerging from KLIPS.
Firewall rules can recognise packets emerging from IPsec. They are marked as arriving on an interface such as ipsec0, rather than eth0, ppp0 or whatever.
It is therefore reasonably straightforward to filter these packets in whatever way suits your situation.

Modifying existing rules

In some cases rules that work fine before you add IPsec may require modification to work with IPsec.

This is especially likely for rules that deal with interfaces on the Internet side of your system. IPsec adds a new interface; often the rules must change to take account of that.

For example, consider the rules given in this section of the Netfilter documentation:

Most people just have a single PPP connection to the Internet, and don't
want anyone coming back into their network, or the firewall:

    ## Insert connection-tracking modules (not needed if built into kernel).
    # insmod ip_conntrack
    # insmod ip_conntrack_ftp

    ## Create chain which blocks new connections, except if coming from inside.
    # iptables -N block
    # iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT
    # iptables -A block -m state --state NEW -i ! ppp0 -j ACCEPT
    # iptables -A block -j DROP

    ## Jump to that chain from INPUT and FORWARD chains.
    # iptables -A INPUT -j block
    # iptables -A FORWARD -j block

On an IPsec gateway, those rules may need to be modified. The above allows new connections from anywhere except ppp0. That means new connections from ipsec0 are allowed.

Do you want to allow anyone who can establish an IPsec connection to your gateway to initiate TCP connections to any service on your network? Almost certainly not if you are using opportunistic encryption. Quite possibly not even if you have only explicitly configured connections.

To disallow incoming connections from ipsec0, change the middle section above to:

    ## Create chain which blocks new connections, except if coming from inside.
    # iptables -N block
    # iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT
    # iptables -A block -m state --state NEW -i ppp+ -j DROP
    # iptables -A block -m state --state NEW -i ipsec+ -j DROP
    # iptables -A block -m state --state NEW -i -j ACCEPT
    # iptables -A block -j DROP
The original rules accepted NEW connections from anywhere except ppp0. This version drops NEW connections from any PPP interface (ppp+) and from any ipsec interface (ipsec+), then accepts the survivors.

Of course, these are only examples. You will need to adapt them to your own situation.

Published rule sets

Several sets of firewall rules that work with FreeS/WAN are available.

Scripts based on Ranch's work

One user, Rob Hutton, posted his boot time scripts to the mailing list, and we included them in previous versions of this documentation. They are still available from our web site. However, they were for an earlier FreeS/WAN version so we no longer recommend them. Also, they had some bugs. See this message.

Those scripts were based on David Ranch's scripts for his "Trinity OS" for setting up a secure Linux. Check his home page for the latest version and for information on his book on securing Linux. If you are going to base your firewalling on Ranch's scripts, we recommend using his latest version, and sending him any IPsec modifications you make for incorporation into later versions.

The Seattle firewall

We have had several mailing lists reports of good results using FreeS/WAN with Seawall (the Seattle Firewall). See that project's home page on Sourceforge.

The RCF scripts

Another set of firewall scripts with IPsec support are the RCF or rc.firewall scripts. See their home page.

Asgard scripts

Asgard's Realm has set of firewall scripts with FreeS/WAN support, for 2.4 kernels and iptables.

User scripts from the mailing list

One user gave considerable detail on his scripts, including supporting IPX through the tunnel. His message was too long to conveniently be quoted here, so I've put it in a separate file.

Calling firewall scripts, named in ipsec.conf(5)

The ipsec.conf(5) configuration file has three pairs of parameters used to specify an interface between FreeS/WAN and firewalling code.

Note that using these is not required if you have a static firewall setup. In that case, you just set your firewall up at boot time (in a way that permits the IPsec connections you want) and do not change it thereafter. Omit all the FreeS/WAN firewall parameters and FreeS/WAN will not attempt to adjust firewall rules at all. See above for some information on appropriate scripts.

However, if you want your firewall rules to change when IPsec connections change, then you need to use these parameters.

Scripts called at IPsec start and stop

One pair of parmeters are set in the config setup section of the ipsec.conf(5) file and affect all connections:

prepluto=
script to be called before pluto(8) IKE daemon is started.
postpluto=
script to be called after pluto(8) IKE daemon is stopped.
These parameters allow you to change firewall parameters whenever IPsec is started or stopped.

They can also be used in other ways. For example, you might have prepluto add a module to your kernel for the secure network interface or make a dialup connection, and then have postpluto remove the module or take the connection down.

Scripts called at connection up and down

The other parameters are set in connection descriptions. They can be set in individual connection descriptions, and could even call different scripts for each connection for maximum flexibility. In most applications, however, it makes sense to use only one script and to call it from conn %default section so that it applies to all connections.

You can:

either
set leftfirewall=yes or rightfirewall=yes to use our supplied default script
or
assign a name in a leftupdown= or rightupdown= line to use your own script

Note that only one of these should be used. You cannot sensibly use both. Since our default script is obsolete (designed for firewalls using ipfwadm(8) on 2.0 kernels), most users who need this service will need to write a custom script.

The default script

We supply a default script named _updown.
leftfirewall=
rightfirewall=
indicates that the gateway is doing firewalling and that pluto(8) should poke holes in the firewall as required.
Set these to yes and Pluto will call our default script _updown with appropriate arguments whenever it: The supplied default _updown script is appropriate for simple cases using the ipfwadm(8) wall scriptstforward to filter these packets in whatever way suits your situation.

Modifying existing rules

In some cases rules that work fine before you add IPsec may require modification to work with IPsec.

This is especially likely for rules that deal with interfaces on the Internet side of your system. IPsec adds a new interface; often the rules must change to take account of that.

For example, consider the rules given in this section of the Netfilter documentation:

Most people just have a single PPP connection to the Internet, and don't
want anyone coming back into their network, or the firewall:

    ## Insert connection-tracking modules (not needed if built into kernel).
    # insmod ip_conntrack
    # insmod ip_conntrack_ftp

    ## Create chain which blocks new connections, except if coming from inside.
    # iptables -N block
    # iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT
    # iptables -A block -m state --state NEW -i ! ppp0 -j ACCEPT
    # iptables -A block -j DROP

    ## Jump to that chain from INPUT and FORWARD chains.
    # iptables -A INPUT -j block
    # iptables -A FORWARD -j block

On an IPsec gateway, those rules may need to be modified. The above allows new connections from anywhere except ppp0. That means new connections from ipsec0 are allowed.

Do you want to allow anyone who can establish an IPsec connection to your gateway to initiate TCP connections to any service on your network? Almost certainly not if you are using opportunistic encryption. Quite possibly not even if you have only explicitly configured connections.

To disallow incoming connections from ipsec0, change the middle section above to:

    ## Create chain which blocks new connections, except if coming from inside.
    # iptables -N block
    # iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT
    # iptables -A block -m state --state NEW -i ppp+ -j DROP
    # iptables -A block -m state --state NEW -i ipsec+ -j DROP
    # iptables -A block -m state --state NEW -i -j ACCEPT
    # iptables -A block -j DROP
The original rules accepted NEW connections from anywhere except ppp0. This version drops NEW connections from any PPP interface (ppp+) and from any ipsec interface (ipsec+), then accepts the survivors.

Of course, these are only examples. You will need to adapt them to your own situation.

Published rule sets

Several sets of firewall rules that work with FreeS/WAN are available.

Scripts based on Ranch's work

One user, Rob Hutton, posted his boot time scripts to the mailing list, and we included them in previous versions of this documentation. They are still available from our web site. However, they were for an earlier FreeS/WAN version so we no longer recommend them. Also, they had some bugs. See this message.

Those scripts were based on David Ranch's scripts for his "Trinity OS" for setting up a secure Linux. Check his home page for the latest version and for information on his book on securing Linux. If you are going to base your firewalling on Ranch's scripts, we recommend using his latest version, and sending him any IPsec modifications you make for incorporation into later versions.

The Seattle firewall

We have had several mailing lists reports of good results using FreeS/WAN with Seawall (the Seattle Firewall). See that project's home page on Sourceforge.

The RCF scripts

Another set of firewall scripts with IPsec support are the RCF or rc.firewall scripts. See their home page.

Asgard scripts

Asgard's Realm has set of firewall scripts with FreeS/WAN support, for 2.4 kernels and iptables.

User scripts from the mailing list

One user gave considerable detail on his scripts, including supporting IPX through the tunnel. His message was too long to conveniently be quoted here, so I've put it in a separate file.

Calling firewall scripts, named in ipsec.conf(5)

The ipsec.conf(5) configuration file has three pairs of parameters used to specify an interface between FreeS/WAN and firewalling code.

Note that using these is not required if you have a static firewall setup. In that case, you just set your firewall up at boot time (in a way that permits the IPsec connections you want) and do not change it thereafter. Omit all the FreeS/WAN firewall parameters and FreeS/WAN will not attempt to adjust firewall rules at all. See above for some information on appropriate scripts.

However, if you want your firewall rules to change when IPsec connections change, then you need to use these parameters.

Scripts called at IPsec start and stop

One pair of parmeters are set in the config setup section of the ipsec.conf(5) file and affect all connections:

prepluto=
script to be called before pluto(8) IKE daemon is started.
postpluto=
script to be called after pluto(8) IKE daemon is stopped.
These parameters allow you to change firewall parameters whenever IPsec is started or stopped.

They can also be used in other ways. For example, you might have prepluto add a module to your kernel for the secure network interface or make a dialup connection, and then have postpluto remove the module or take the connection down.

Scripts called at connection up and down

The other parameters are set in connection descriptions. They can be set in individual connection descriptions, and could even call different scripts for each connection for maximum flexibility. In most applications, however, it makes sense to use only one script and to call it from conn %default section so that it applies to all connections.

You can:

either
set leftfirewall=yes or rightfirewall=yes to use our supplied default script
or
assign a name in a leftupdown= or rightupdown= line to use your own script

Note that only one of these should be used. You cannot sensibly use both. Since our default script is obsolete (designed for firewalls using ipfwadm(8) on 2.0 kernels), most users who need this service will need to write a custom script.

The default script

We supply a default script named _updown.
leftfirewall=
rightfirewall=
indicates that the gateway is doing firewalling and that pluto(8) should poke holes in the firewall as required.
Set these to yes and Pluto will call our default script _updown with appropriate arguments whenever it: The supplied default _updown script is appropriate for simple cases using the ipfwadm(8) wall scriptstforward to filter these packets in whatever way suits your situation.

Modifying existing rules

In some cases rules that work fine before you add IPsec may require modification to work with IPsec.

This is especially likely for rules that deal with interfaces on the Internet side of your system. IPsec adds a new interface; often the rules must change to take account of that.

For example, consider the rules given in this section of the Netfilter documentation:

Most people just have a single PPP connection to the Internet, and don't
want anyone coming back into their network, or the firewall:

    ## Insert connection-tracking modules (not needed if built into kernel).
    # insmod ip_conntrack
    # insmod ip_conntrack_ftp

    ## Create chain which blocks new connections, except if coming from inside.
    # iptables -N block
    # iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT
    # iptables -A block -m state --state NEW -i ! ppp0 -j ACCEPT
    # iptables -A block -j DROP

    ## Jump to that chain from INPUT and FORWARD chains.
    # iptables -A INPUT -j block
    # iptables -A FORWARD -j block

On an IPsec gateway, those rules may need to be modified. The above allows new connections from anywhere except ppp0. That means new connections from ipsec0 are allowed.

Do you want to allow anyone who can establish an IPsec connection to your gateway to initiate TCP connections to any service on your network? Almost certainly not if you are using opportunistic encryption. Quite possibly not even if you have only explicitly configured connections.

To disallow incoming connections from ipsec0, change the middle section above to:

    ## Create chain which blocks new connections, except if coming from inside.
    # iptables -N block
    # iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT
    # iptables -A block -m state --state NEW -i ppp+ -j DROP
    # iptables -A block -m state --state NEW -i ipsec+ -j DROP
    # iptables -A block -m state --state NEW -i -j ACCEPT
    # iptables -A block -j DROP
The original rules accepted NEW connections from anywhere except ppp0. This version drops NEW connections from any PPP interface (ppp+) and from any ipsec interface (ipsec+), then accepts the survivors.

Of course, these are only examples. You will need to adapt them to your own situation.

Published rule sets

Several sets of firewall rules that work with FreeS/WAN are available.

Scripts based on Ranch's work

One user, Rob Hutton, posted his boot time scripts to the mailing list, and we included them in previous versions of this documentation. They are still available from our web site. However, they were for an earlier FreeS/WAN version so we no longer recommend them. Also, they had some bugs. See this message.

Those scripts were based on David Ranch's scripts for his "Trinity OS" for setting up a secure Linux. Check his home page for the latest version and for information on his book on securing Linux. If you are going to base your firewalling on Ranch's scripts, we recommend using his latest version, and sending him any IPsec modifications you make for incorporation into later versions.

The Seattle firewall

We have had several mailing lists reports of good results using FreeS/WAN with Seawall (the Seattle Firewall). See that project's home page on Sourceforge.

The RCF scripts

Another set of firewall scripts with IPsec support are the RCF or rc.firewall scripts. See their home page.

Asgard scripts

Asgard's Realm has set of firewall scripts with FreeS/WAN support, for 2.4 kernels and iptables.

User scripts from the mailing list

One user gave considerable detail on his scripts, including supporting IPX through the tunnel. His message was too long to conveniently be quoted here, so I've put it in a separate file.

Calling firewall scripts, named in ipsec.conf(5)

The ipsec.conf(5) configuration file has three pairs of parameters used to specify an interface between FreeS/WAN and firewalling code.

Note that using these is not required if you have a static firewall setup. In that case, you just set your firewall up at boot time (in a way that permits the IPsec connections you want) and do not change it thereafter. Omit all the FreeS/WAN firewall parameters and FreeS/WAN will not attempt to adjust firewall rules at all. See above for some information on appropriate scripts.

However, if you want your firewall rules to change when IPsec connections change, then you need to use these parameters.

Scripts called at IPsec start and stop

One pair of parmeters are set in the config setup section of the ipsec.conf(5) file and affect all connections:

prepluto=
script to be called before pluto(8) IKE daemon is started.
postpluto=
script to be called after pluto(8) IKE daemon is stopped.
These parameters allow you to change firewall parameters whenever IPsec is started or stopped.

They can also be used in other ways. For example, you might have prepluto add a module to your kernel for the secure network interface or make a dialup connection, and then have postpluto remove the module or take the connection down.

Scripts called at connection up and down

The other parameters are set in connection descriptions. They can be set in individual connection descriptions, and could even call different scripts for each connection for maximum flexibility. In most applications, however, it makes sense to use only one script and to call it from conn %default section so that it applies to all connections.

You can:

either
set leftfirewall=yes or rightfirewall=yes to use our supplied default script
or
assign a name in a leftupdown= or rightupdown= line to use your own script

Note that only one of these should be used. You cannot sensibly use both. Since our default script is obsolete (designed for firewalls using ipfwadm(8) on 2.0 kernels), most users who need this service will need to write a custom script.

The default script

We supply a default script named _updown.
leftfirewall=
rightfirewall=
indicates that the gateway is doing firewalling and that pluto(8) should poke holes in the firewall as required.
Set these to yes and Pluto will call our default script _updown with appropriate arguments whenever it: The supplied default _updown script is appropriate for simple cases using the ipfwadm(8) wall scriptstforward to filter these packets in whatever way suits your situation.

Modifying existing rules

In some cases rules that work fine before you add IPsec may require modification to work with IPsec.

This is especially likely for rules that deal with interfaces on the Internet side of your system. IPsec adds a new interface; often the rules must change to take account of that.

For example, consider the rules given in this section of the Netfilter documentation:

Most people just have a single PPP connection to the Internet, and don't
want anyone coming back into their network, or the firewall:

    ## Insert connection-tracking modules (not needed if built into kernel).
    # insmod ip_conntrack
    # insmod ip_conntrack_ftp

    ## Create chain which blocks new connections, except if coming from inside.
    # iptables -N block
    # iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT
    # iptables -A block -m state --state NEW -i ! ppp0 -j ACCEPT
    # iptables -A block -j DROP

    ## Jump to that chain from INPUT and FORWARD chains.
    # iptables -A INPUT -j block
    # iptables -A FORWARD -j block

On an IPsec gateway, those rules may need to be modified. The above allows new connections from anywhere except ppp0. That means new connections from ipsec0 are allowed.

Do you want to allow anyone who can establish an IPsec connection to your gateway to initiate TCP connections to any service on your network? Almost certainly not if you are using opportunistic encryption. Quite possibly not even if you have only explicitly configured connections.

To disallow incoming connections from ipsec0, change the middle section above to:

    ## Create chain which blocks new connections, except if coming from inside.
    # iptables -N block
    # iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT
    # iptables -A block -m state --state NEW -i ppp+ -j DROP
    # iptables -A block -m state --state NEW -i ipsec+ -j DROP
    # iptables -A block -m state --state NEW -i -j ACCEPT
    # iptables -A block -j DROP
The original rules accepted NEW connections from anywhere except ppp0. This version drops NEW connections from any PPP interface (ppp+) and from any ipsec interface (ipsec+), then accepts the survivors.

Of course, these are only examples. You will need to adapt them to your own situation.

Published rule sets

Several sets of firewall rules that work with FreeS/WAN are available.

Scripts based on Ranch's work

One user, Rob Hutton, posted his boot time scripts to the mailing list, and we included them in previous versions of this documentation. They are still available from our web site. However, they were for an earlier FreeS/WAN version so we no longer recommend them. Also, they had some bugs. See this message.

Those scripts were based on David Ranch's scripts for his "Trinity OS" for setting up a secure Linux. Check his home page for the latest version and for information on his book on securing Linux. If you are going to base your firewalling on Ranch's scripts, we recommend using his latest version, and sending him any IPsec modifications you make for incorporation into later versions.

The Seattle firewall

We have had several mailing lists reports of good results using FreeS/WAN with Seawall (the Seattle Firewall). See that project's home page on Sourceforge.

The RCF scripts

Another set of firewall scripts with IPsec support are the RCF or rc.firewall scripts. See their home page.

Asgard scripts

Asgard's Realm has set of firewall scripts with FreeS/WAN support, for 2.4 kernels and iptables.

User scripts from the mailing list

One user gave considerable detail on his scripts, including supporting IPX through the tunnel. His message was too long to conveniently be quoted here, so I've put it in a separate file.

Calling firewall scripts, named in ipsec.conf(5)

The ipsec.conf(5) configuration file has three pairs of parameters used to specify an interface between FreeS/WAN and firewalling code.

Note that using these is not required if you have a static firewall setup. In that case, you just set your firewall up at boot time (in a way that permits the IPsec connections you want) and do not change it thereafter. Omit all the FreeS/WAN firewall parameters and FreeS/WAN will not attempt to adjust firewall rules at all. See above for some information on appropriate scripts.

However, if you want your firewall rules to change when IPsec connections change, then you need to use these parameters.

Scripts called at IPsec start and stop

One pair of parmeters are set in the config setup section of the ipsec.conf(5) file and affect all connections:

prepluto=
script to be called before pluto(8) IKE daemon is started.
postpluto=
script to be called after pluto(8) IKE daemon is stopped.
These parameters allow you to change firewall parameters whenever IPsec is started or stopped.

They can also be used in other ways. For example, you might have prepluto add a module to your kernel for the secure network interface or make a dialup connection, and then have postpluto remove the module or take the connection down.

Scripts called at connection up and down

The other parameters are set in connection descriptions. They can be set in individual connection descriptions, and could even call different scripts for each connection for maximum flexibility. In most applications, however, it makes sense to use only one script and to call it from conn %default section so that it applies to all connections.

You can:

either
set leftfirewall=yes or rightfirewall=yes to use our supplied default script
or
assign a name in a leftupdown= or rightupdown= line to use your own script

Note that only one of these should be used. You cannot sensibly use both. Since our default script is obsolete (designed for firewalls using ipfwadm(8) on 2.0 kernels), most users who need this service will need to write a custom script.

The default script

We supply a default script named _updown.
leftfirewall=
rightfirewall=
indicates that the gateway is doing firewalling and that pluto(8) should poke holes in the firewall as required.
Set these to yes and Pluto will call our default script _updown with appropriate arguments whenever it: The supplied default _updown script is appropriate for simple cases using the ipfwadm(8) wall scriptstforward to filter these packets in whatever way suits your situation.

Modifying existing rules

In some cases rules that work fine before you add IPsec may require modification to work with IPsec.

This is especially likely for rules that deal with interfaces on the Internet side of your system. IPsec adds a new interface; often the rules must change to take account of that.

For example, consider the rules given in this section of the Netfilter documentation:

Most people just have a single PPP connection to the Internet, and don't
want anyone coming back into their network, or the firewall:

    ## Insert connection-tracking modules (not needed if built into kernel).
    # insmod ip_conntrack
    # insmod ip_conntrack_ftp

    ## Create chain which blocks new connections, except if coming from inside.
    # iptables -N block
    # iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT
    # iptables -A block -m state --state NEW -i ! ppp0 -j ACCEPT
    # iptables -A block -j DROP

    ## Jump to that chain from INPUT and FORWARD chains.
    # iptables -A INPUT -j block
    # iptables -A FORWARD -j block

On an IPsec gateway, those rules may need to be modified. The above allows new connections from anywhere except ppp0. That means new connections from ipsec0 are allowed.

Do you want to allow anyone who can establish an IPsec connection to your gateway to initiate TCP connections to any service on your network? Almost certainly not if you are using opportunistic encryption. Quite possibly not even if you have only e