FireBrick Road Warrior FireBrick Config: Difference between revisions
m (→Overview) |
|||
Line 6: | Line 6: | ||
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. |
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: |
|||
'''Separate pool:''' |
|||
Choose an IP range not used anywhere else in your FB config |
|||
(and to avoid confusion choose something non-routable eg 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. |
|||
==Proxy ARP== |
==Proxy ARP== |
Revision as of 20:28, 17 February 2016
FireBrick IPsec config
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:
Separate pool: Choose an IP range not used anywhere else in your FB config
(and to avoid confusion choose something non-routable eg 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.
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.
Configuration
The basic server config is in ipsec-ike containing a connection and roaming entry, e.g.
<ipsec-ike>
<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]"/>
</ipsec-ike>
Each roaming user then needs an eap user record.
<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:
- Allowing IPsec traffic in to the FireBrick
- Controlling what an IPsec client, once connected, has access to
Allow IPsec traffic in to the FireBrick
- See: IPsec_Firewall
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:
- Firewal 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)