L2TP Client: FireBrick

Back up to the Incoming L2TP Category
From AAISP Support Site
Revision as of 11:53, 10 Mayıs 2016 by AA-Andrew (talk | contribs) (Created page with "__NOTOC__<indicator name="L2TP">link=:Category:Incoming_L2TP|30px|Back up to the Incoming L2TP Category</indicator> Category:Incoming_L2TP == FireBr...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

FireBrick FB2500/2700 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"
           ip="90.155.53.19"
           graph="AAISP"
           table="1"
           payload-table="0"
           username="example@a"
           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.