L2TP Client: FireBrick: Difference between revisions

Back up to the Incoming L2TP Category
From AAISP Support Site
mNo edit summary
(6 intermediate revisions by 3 users not shown)
Line 1: Line 1:
__NOTOC__<indicator name="L2TP">[[File:Menu-L2TP.svg|link=:Category:Incoming_L2TP|30px|Back up to the Incoming L2TP Category]]</indicator>
__NOTOC__<indicator name="L2TP">[[File:Menu-L2TP.svg|link=:Category:Incoming L2TP|30px|Back up to the Incoming L2TP Category]]</indicator>
[[Category:Incoming_L2TP]]
[[Category:Incoming L2TP]]
== FireBrick FB2500/2700 Fully Loaded ==
== FireBrick FB2500/FB2700/FB2900 Fully Loaded ==


The FireBrick can connect as an L2TP client for fallback and for its main connection. One thing to watch out for is making sure that the FB doesn't set its own gateway to be the tunnel (which would logically send tunnel packets up the tunnel, which is horrid). You can get around this by using separate routing tables.
The FireBrick can connect as an L2TP client for fallback and for its main connection. One thing to watch out for is making sure that the FB doesn't set its own gateway to be the tunnel (which would logically send tunnel packets up the tunnel, which is horrid). You can get around this by using separate routing tables.
Line 7: Line 7:
This example is for L2TP being the main connection:
This example is for L2TP being the main connection:


<syntaxhighlight lang="xml">
<interface name="WAN"
<interface name="WAN"
port="WAN1"
port="WAN1"
Line 14: Line 15:
<l2tp>
<l2tp>
<outgoing name="AAISP"
<outgoing name="AAISP"
hostname="AAISP"
ip="90.155.53.19"
ip="90.155.53.19"
graph="AAISP"
graph="AAISP"
table="1"
table="1"
payload-table="0"
payload-table="0"
username="example@a"
username="example@a.1"
password="secret"
password="secret"
tcp-mss-fix="true"
tcp-mss-fix="true"
comment="L2TP tunnel to AAISP"/>
comment="L2TP tunnel to AAISP"/>
</l2tp>
</l2tp>
</syntaxhighlight>


You can set to fall back to NAT if the tunnel is down. Traffic on routing table 0 won't have a default gateway if the L2TP is down, so will match this rule set that has target interface "nowhere":
You can set to fall back to NAT if the tunnel is down. Traffic on routing table 0 won't have a default gateway if the L2TP is down, so will match this rule set that has target interface "nowhere":


<syntaxhighlight lang="xml">
<rule-set name="Fallback"
<rule-set name="Fallback"
target-interface="nowhere"
target-interface="nowhere"
Line 35: Line 39:
action="accept"/>
action="accept"/>
</rule-set>
</rule-set>
</syntaxhighlight>


If the L2TP is being used for fallback, you are probably better off setting the routing table for the L2TP to something other than 0. Remember firewall rules only apply to single routing tables. You can then use profiles to bring the L2TP in to service in the even of the PPP going down etc.
If the L2TP is being used for fallback, you are probably better off setting the routing table for the L2TP to something other than 0. Remember firewall rules only apply to single routing tables. You can then use profiles to bring the L2TP in to service in the even of the PPP going down etc.

===Virgin Media===
Some customers may be tunnelling into us via a Virgin Media connection (typically a Virgin Media router connected directly to the FB). Customers doing this may find that the tunnel can drop and not recover. You can resolve this by setting '''min-retry''' to 1. This is a hidden option, so you will need to click 'show all' under the tunnel settings.

Revision as of 22:33, 26 March 2022

FireBrick FB2500/FB2700/FB2900 Fully Loaded

The FireBrick can connect as an L2TP client for fallback and for its main connection. One thing to watch out for is making sure that the FB doesn't set its own gateway to be the tunnel (which would logically send tunnel packets up the tunnel, which is horrid). You can get around this by using separate routing tables.

This example is for L2TP being the main connection:

 <interface name="WAN"
            port="WAN1"
            table="1"
            comment="DHCP client">

 <l2tp>
  <outgoing name="AAISP"
            hostname="AAISP"
            ip="90.155.53.19"
            graph="AAISP"
            table="1"
            payload-table="0"
            username="example@a.1"
            password="secret"
            tcp-mss-fix="true"
            comment="L2TP tunnel to AAISP"/>
 </l2tp>

You can set to fall back to NAT if the tunnel is down. Traffic on routing table 0 won't have a default gateway if the L2TP is down, so will match this rule set that has target interface "nowhere":

 <rule-set name="Fallback"
           target-interface="nowhere"
           no-match-action="continue"
           comment="NAT fallback if can't establish L2TP">
  <rule name="NAT"
        set-nat="true"
        set-table="1"
        action="accept"/>
 </rule-set>

If the L2TP is being used for fallback, you are probably better off setting the routing table for the L2TP to something other than 0. Remember firewall rules only apply to single routing tables. You can then use profiles to bring the L2TP in to service in the even of the PPP going down etc.

Virgin Media

Some customers may be tunnelling into us via a Virgin Media connection (typically a Virgin Media router connected directly to the FB). Customers doing this may find that the tunnel can drop and not recover. You can resolve this by setting min-retry to 1. This is a hidden option, so you will need to click 'show all' under the tunnel settings.