FireBrick Road Warrior FireBrick Config: Difference between revisions

Back up to the FireBrick Road Warrior Category Page
From AAISP Support Site
(15 intermediate revisions by 2 users not shown)
Line 1: Line 1:
<indicator name="RoadW">[[File:Menu-Road-Warrior.svg|link=:Category:FireBrick_IPsec_Road_Warrior|30px|Back up to the FireBrick Road Warrior Category Page]]</indicator>
<indicator name="RoadW">[[File:Menu-Road-Warrior.svg|link=:Category:FireBrick IPsec Road Warrior|30px|Back up to the FireBrick Road Warrior Category Page]]</indicator>
= FireBrick IPsec config =
= FireBrick IPsec config =


==A note on IP Allocations==
==Overview==
In this example we are assuming you can allocate some IP addresses on you LAN. You do this by picking a range of addresses and setting up a roaming-pool (see below). You need to ensure the IP range does not clash with devices on the LAN and is not in the DHCP ranges that could allocate to the LAN.

The FireBrick needs a configuration for the connection, and roaming pools and user identities. The connection can be used for any number of devices at once with the same pool of IP addresses; each would have a user name and password defined.

===A note on IP Allocations===


There are two common ways to use the IPsec roaming pools:
There are two common ways to use the IPsec roaming pools:


'''Separate pool:'''
'''Separate pool:'''

Choose an IP range not used anywhere else in your FB config
Choose an IP range not used anywhere else in your FB config
(and to avoid confusion choose something non-routable eg from 10...)
(and to avoid confusion choose something non-routable e.g. from 10...)
Set the NAT flag on the ipsec roaming pool definition.
Set the NAT flag on the ipsec roaming pool definition.


In this scenario all traffic arriving at the FB from the remote
In this scenario all traffic arriving at the FB from the remote
device will be NATed (with FB source address) before being routed
device will be NATed (with FB source address) before being routed
onwards. This provides what most people would expect - remote
onwards. This provides what most people would expect - remote
device has a non-routable NATed address. Sessions originating
device has a non-routable NATed address. Sessions originating
on the device can talk to anywhere the FB can - but other
on the device can talk to anywhere the FB can - but other
devices cannot initiate sessions to the remote device.
devices cannot initiate sessions to the remote device.


'''IPs from the existing LAN'''
'''IPs from the existing LAN'''

Choose a "real" range of IP addresses already known to the FB.
Choose a "real" range of IP addresses already known to the FB.
Typically this would be a subset of one of the FB's LAN subnets.
Typically this would be a subset of one of the FB's LAN subnets.
[Take care if doing this to not have an overlap with any DHCP
[Take care if doing this to not have an overlap with any DHCP
allocations which the FB may do on that subnet.] In this case
allocations which the FB may do on that subnet.] In this case
the roaming pool NAT setting should not be set. Normally you
the roaming pool NAT setting should not be set. Normally you
will want your FB LAN devices to be able to communicate with the
will want your FB LAN devices to be able to communicate with the
remote client, so you should set "proxy-arp" on the FB subnet
remote client, so you should set "proxy-arp" on the FB subnet
definition.
definition.


In this scenario, the remote device behaves just like a device
In this scenario, the remote device behaves just like a device
connected on the LAN, and, if the LAN subnet is routable, the
connected on the LAN, and, if the LAN subnet is routable, the
remote device will also be able to communicate externally.
remote device will also be able to communicate externally.

'''Think about the NAT'''

A problem arises however when the LAN subnet is non-routable (RFC1918 IPs, e.g. 192.168.x.x).
In this case the LAN subnet is usually marked NAT in the FB config,
so LAN devices can communicate externally (obviously for outgoing
sessions only). However, for roadwarrior devices the FB has to
know that incoming IPsec packets for the LAN (or the FB) should not
be NATed, but those destined for elsewhere should be (assuming
the roadwarrior devices should be given internet access).

The roaming-pool NAT flag will nat everything, but the FB LAN NAT
flag won't be looked at (it only applies to real traffic originating
on the LAN and destined off-LAN).

This is overcome, either, by using mapping rules, or by disabling NAT on the LAN subnet and instead enabling NAT on the external internet connection, e.g. in most cases this would be the PPP connection.

==Overview==
In this example we are assuming you can allocate some IP addresses on you LAN. You do this by picking a range of addresses and setting up a roaming-pool (see below). You need to ensure the IP range does not clash with devices on the LAN and is not in the DHCP ranges that could allocate to the LAN.

The FireBrick needs a configuration for the connection, and roaming pools and user identities. The connection can be used for any number of devices at once with the same pool of IP addresses; each would have a user name and password defined.


==Proxy ARP==
==Proxy ARP==
Line 44: Line 62:
The basic server config is in <tt>ipsec-ike</tt> containing a <tt>connection</tt> and <tt>roaming</tt> entry, e.g.
The basic server config is in <tt>ipsec-ike</tt> containing a <tt>connection</tt> and <tt>roaming</tt> entry, e.g.


<syntaxhighlight>
<syntaxhighlight lang=xml>
<ipsec-ike>
<ipsec-ike force-NAT="0.0.0.0/0">
<connection name="server" roaming-pool="roam-pool" auth-method="Certificate" peer-auth-method="EAP" mode="Wait" local-ID="FQDN:server.example.com"/>
<connection name="server" roaming-pool="roam-pool" auth-method="Certificate" peer-auth-method="EAP" mode="Wait" local-ID="FQDN:server.example.com"/>
<roaming name="roam-pool" ip="[ranges of LAN IPs]" DNS="[DNS, e.g. 8.8.8.8]"/>
<roaming name="roam-pool" ip="[ranges of LAN IPs, inc IPv6]" DNS="[DNS, e.g. 8.8.8.8]"/>
</ipsec-ike>
</ipsec-ike>
</syntaxhighlight>
</syntaxhighlight>


Note: the force-NAT="0.0.0.0/0" forces keep-alives which are needed when NAT is involved between the endpoints but and also helps where stateful firewalls are in the route too. (without this set, you may find that the ipsec tunnel drops every hour or so)
Each roaming user then needs an <tt>eap</tt> user record.

Each roaming user then needs an <tt>eap</tt> user record. This goes with any user entries near the top of the config.


<syntaxhighlight>
<syntaxhighlight lang=xml>
<eap name="fred" full-name="Fred Bloggs" password="[password]" subsystem="IPsec" methods="MSChapV2"/>
<eap name="fred" full-name="Fred Bloggs" password="[password]" subsystem="IPsec" methods="MSChapV2"/>
</syntaxhighlight>
</syntaxhighlight>


Here is how the above three config sections look in the User Interface (UI):
Here is how the above three config sections look in the User Interface (UI):
<gallery widths=250px caption="FireBrick SCreenshots">
<gallery widths=250px caption="FireBrick Screenshots">
FireBrick-IPsec-IKESettings.png|IKE Settings (UI). (Config - Edit - Tunnels - IPsec - Add, IKE connection)
FireBrick-IPsec-IKESettings.png|IKE Settings (UI). (Config - Edit - Tunnels - IPsec - Add, IKE connection)
FireBrick-IPsec-RoamingPool.png|Roaming Pool Settings (UI). (Config - Edit - Tunnels - IPsec - Add, IKE roaming IP pools
FireBrick-IPsec-RoamingPool.png|Roaming Pool Settings (UI). (Config - Edit - Tunnels - IPsec - Add, IKE roaming IP pools
Line 71: Line 91:


==Allow IPsec traffic in to the FireBrick==
==Allow IPsec traffic in to the FireBrick==
*See: [[IPsec_Firewall]]
*See: [[IPsec Firewall]]


==Controlling client traffic==
==Controlling client traffic==


You will also want to look at the Firewall on the FireBrick and allow traffic where required, for example, to Allow the IPsec users to connect to the Internet via your PPPoE connections use something like:
You will also want to look at the Firewall on the FireBrick and allow traffic where required, for example, to Allow the IPsec users to connect to the Internet via your PPPoE connections use something like:
<syntaxhighlight>
<syntaxhighlight lang=xml>
<rule-set name="FromIPSec" source-interface="ipsec" no-match-action="continue">
<rule-set name="FromIPSec" source-interface="ipsec" no-match-action="continue">
<rule name="AllowInternet" target-interface="pppoe" action="accept"/>
<rule name="AllowInternet" target-interface="pppoe" action="accept"/>
Line 84: Line 104:
===DNS Servers===
===DNS Servers===
If you set the DNS servers in the pool to be the FireBrick's IP address then you will need to allow access. This will be done with:
If you set the DNS servers in the pool to be the FireBrick's IP address then you will need to allow access. This will be done with:
*Firewal rules (port 53 to the FireBrick from IPsec
*Firewall rules (port 53 to the FireBrick from IPsec)
*Editing the DNS Service to allow non-local users, we'd recommend using an Allow list that includes the IPsec clients as well as the LAN clients if they are to also use the FireBrick as their DNS resolver. (Setup - General System Services - DNS)
*Editing the DNS Service to allow non-local users, we'd recommend using an Allow list that includes the IPsec clients as well as the LAN clients if they are to also use the FireBrick as their DNS resolver. (Setup - General System Services - DNS)


[[Category:FireBrick_IPsec_Road_Warrior|FireBrick Config]]
[[Category:FireBrick IPsec Road Warrior|FireBrick Config]]

Revision as of 09:25, 14 December 2018

FireBrick IPsec config

A note on IP Allocations

There are two common ways to use the IPsec roaming pools:

Separate pool:

Choose an IP range not used anywhere else in your FB config (and to avoid confusion choose something non-routable e.g. from 10...) Set the NAT flag on the ipsec roaming pool definition.

In this scenario all traffic arriving at the FB from the remote device will be NATed (with FB source address) before being routed onwards. This provides what most people would expect - remote device has a non-routable NATed address. Sessions originating on the device can talk to anywhere the FB can - but other devices cannot initiate sessions to the remote device.

IPs from the existing LAN

Choose a "real" range of IP addresses already known to the FB. Typically this would be a subset of one of the FB's LAN subnets. [Take care if doing this to not have an overlap with any DHCP allocations which the FB may do on that subnet.] In this case the roaming pool NAT setting should not be set. Normally you will want your FB LAN devices to be able to communicate with the remote client, so you should set "proxy-arp" on the FB subnet definition.

In this scenario, the remote device behaves just like a device connected on the LAN, and, if the LAN subnet is routable, the remote device will also be able to communicate externally.

Think about the NAT

A problem arises however when the LAN subnet is non-routable (RFC1918 IPs, e.g. 192.168.x.x). In this case the LAN subnet is usually marked NAT in the FB config, so LAN devices can communicate externally (obviously for outgoing sessions only). However, for roadwarrior devices the FB has to know that incoming IPsec packets for the LAN (or the FB) should not be NATed, but those destined for elsewhere should be (assuming the roadwarrior devices should be given internet access).

The roaming-pool NAT flag will nat everything, but the FB LAN NAT flag won't be looked at (it only applies to real traffic originating on the LAN and destined off-LAN).

This is overcome, either, by using mapping rules, or by disabling NAT on the LAN subnet and instead enabling NAT on the external internet connection, e.g. in most cases this would be the PPP connection.

Overview

In this example we are assuming you can allocate some IP addresses on you LAN. You do this by picking a range of addresses and setting up a roaming-pool (see below). You need to ensure the IP range does not clash with devices on the LAN and is not in the DHCP ranges that could allocate to the LAN.

The FireBrick needs a configuration for the connection, and roaming pools and user identities. The connection can be used for any number of devices at once with the same pool of IP addresses; each would have a user name and password defined.

Proxy ARP

You also need to set proxy-arp on the LAN interface settings to allow communications to other devices on your LAN. Alternatively you could set private IP addresses in the pool and set the nat setting. You should probably also consider firewalling rules for traffic to/from IPsec connections.

Proxy ARP setting on the subnet

Configuration

The basic server config is in ipsec-ike containing a connection and roaming entry, e.g.

<ipsec-ike force-NAT="0.0.0.0/0">
 <connection name="server" roaming-pool="roam-pool" auth-method="Certificate" peer-auth-method="EAP" mode="Wait" local-ID="FQDN:server.example.com"/>
 <roaming name="roam-pool" ip="[ranges of LAN IPs, inc IPv6]" DNS="[DNS, e.g. 8.8.8.8]"/>
</ipsec-ike>

Note: the force-NAT="0.0.0.0/0" forces keep-alives which are needed when NAT is involved between the endpoints but and also helps where stateful firewalls are in the route too. (without this set, you may find that the ipsec tunnel drops every hour or so)

Each roaming user then needs an eap user record. This goes with any user entries near the top of the config.

 <eap name="fred" full-name="Fred Bloggs" password="[password]" subsystem="IPsec" methods="MSChapV2"/>

Here is how the above three config sections look in the User Interface (UI):

Firewall

There are two aspects to Firewalling:

  1. Allowing IPsec traffic in to the FireBrick
  2. Controlling what an IPsec client, once connected, has access to

Allow IPsec traffic in to the FireBrick

Controlling client traffic

You will also want to look at the Firewall on the FireBrick and allow traffic where required, for example, to Allow the IPsec users to connect to the Internet via your PPPoE connections use something like:

   <rule-set name="FromIPSec" source-interface="ipsec" no-match-action="continue">
      <rule name="AllowInternet" target-interface="pppoe" action="accept"/>
   </rule-set>

DNS Servers

If you set the DNS servers in the pool to be the FireBrick's IP address then you will need to allow access. This will be done with:

  • Firewall rules (port 53 to the FireBrick from IPsec)
  • Editing the DNS Service to allow non-local users, we'd recommend using an Allow list that includes the IPsec clients as well as the LAN clients if they are to also use the FireBrick as their DNS resolver. (Setup - General System Services - DNS)