diff options
Diffstat (limited to 'docs/configexamples')
| -rw-r--r-- | docs/configexamples/azure-vpn-bgp.rst | 130 | ||||
| -rw-r--r-- | docs/configexamples/azure-vpn-dual-bgp.rst | 155 | ||||
| -rw-r--r-- | docs/configexamples/bgp-ipv6-unnumbered.rst | 172 | ||||
| -rw-r--r-- | docs/configexamples/dhcp-relay-through-gre-bridge.rst | 77 | ||||
| -rw-r--r-- | docs/configexamples/ha.rst | 580 | ||||
| -rw-r--r-- | docs/configexamples/index.rst | 19 | ||||
| -rw-r--r-- | docs/configexamples/ospf-unnumbered.rst | 118 | ||||
| -rw-r--r-- | docs/configexamples/tunnelbroker-ipv6.rst | 169 | ||||
| -rw-r--r-- | docs/configexamples/wan-load-balancing.rst | 170 | ||||
| -rw-r--r-- | docs/configexamples/zone-policy.rst | 415 |
10 files changed, 2005 insertions, 0 deletions
diff --git a/docs/configexamples/azure-vpn-bgp.rst b/docs/configexamples/azure-vpn-bgp.rst new file mode 100644 index 00000000..176e0ae0 --- /dev/null +++ b/docs/configexamples/azure-vpn-bgp.rst @@ -0,0 +1,130 @@ +.. _examples-azure-vpn-bgp: + +Route-Based Site-to-Site VPN to Azure (BGP over IKEv2/IPsec) +------------------------------------------------------------ + +This guide shows an example of a route-based IKEv2 site-to-site VPN to +Azure using VTI and BGP for dynamic routing updates. + +For redundant / active-active configurations see `Route-Based Redundant Site-to-Site VPN to Azure (BGP over IKEv2/IPsec) <https://docs.vyos.io/en/crux/appendix/examples/azure-vpn-dual-bgp.html>`_ + +Prerequisites +^^^^^^^^^^^^^ + +- A pair of Azure VNet Gateways deployed in active-passive + configuration with BGP enabled. + +- A local network gateway deployed in Azure representing + the Vyos device, matching the below Vyos settings except for + address space, which only requires the Vyos private IP, in + this example 10.10.0.5/32 + +- A connection resource deployed in Azure linking the + Azure VNet gateway and the local network gateway representing + the Vyos device. + +Example +^^^^^^^ + ++---------------------------------------+---------------------+ +| WAN Interface | eth0 | ++---------------------------------------+---------------------+ +| On-premises address space | 10.10.0.0/16 | ++---------------------------------------+---------------------+ +| Azure address space | 10.0.0.0/16 | ++---------------------------------------+---------------------+ +| Vyos public IP | 198.51.100.3 | ++---------------------------------------+---------------------+ +| Vyos private IP | 10.10.0.5 | ++---------------------------------------+---------------------+ +| Azure VNet Gateway public IP | 203.0.113.2 | ++---------------------------------------+---------------------+ +| Azure VNet Gateway BGP IP | 10.0.0.4 | ++---------------------------------------+---------------------+ +| Pre-shared key | ch00s3-4-s3cur3-psk | ++---------------------------------------+---------------------+ +| Vyos ASN | 64499 | ++---------------------------------------+---------------------+ +| Azure ASN | 65540 | ++---------------------------------------+---------------------+ + +Vyos configuration +^^^^^^^^^^^^^^^^^^ + +- Configure the IKE and ESP settings to match a subset + of those supported by Azure: + +.. code-block:: none + + set vpn ipsec esp-group AZURE compression 'disable' + set vpn ipsec esp-group AZURE lifetime '3600' + set vpn ipsec esp-group AZURE mode 'tunnel' + set vpn ipsec esp-group AZURE pfs 'dh-group2' + set vpn ipsec esp-group AZURE proposal 1 encryption 'aes256' + set vpn ipsec esp-group AZURE proposal 1 hash 'sha1' + + set vpn ipsec ike-group AZURE dead-peer-detection action 'restart' + set vpn ipsec ike-group AZURE dead-peer-detection interval '15' + set vpn ipsec ike-group AZURE dead-peer-detection timeout '30' + set vpn ipsec ike-group AZURE ikev2-reauth 'yes' + set vpn ipsec ike-group AZURE key-exchange 'ikev2' + set vpn ipsec ike-group AZURE lifetime '28800' + set vpn ipsec ike-group AZURE proposal 1 dh-group '2' + set vpn ipsec ike-group AZURE proposal 1 encryption 'aes256' + set vpn ipsec ike-group AZURE proposal 1 hash 'sha1' + +- Enable IPsec on eth0 + +.. code-block:: none + + set vpn ipsec ipsec-interfaces interface 'eth0' + +- Configure a VTI with a dummy IP address + +.. code-block:: none + + set interfaces vti vti1 address '10.10.1.5/32' + set interfaces vti vti1 description 'Azure Tunnel' + +- Clamp the VTI's MSS to 1350 to avoid PMTU blackholes. + +.. code-block:: none + + set firewall options interface vti1 adjust-mss 1350 + +- Configure the VPN tunnel + +.. code-block:: none + + set vpn ipsec site-to-site peer 203.0.113.2 authentication id '198.51.100.3' + set vpn ipsec site-to-site peer 203.0.113.2 authentication mode 'pre-shared-secret' + set vpn ipsec site-to-site peer 203.0.113.2 authentication pre-shared-secret 'ch00s3-4-s3cur3-psk' + set vpn ipsec site-to-site peer 203.0.113.2 authentication remote-id '203.0.113.2' + set vpn ipsec site-to-site peer 203.0.113.2 connection-type 'respond' + set vpn ipsec site-to-site peer 203.0.113.2 description 'AZURE PRIMARY TUNNEL' + set vpn ipsec site-to-site peer 203.0.113.2 ike-group 'AZURE' + set vpn ipsec site-to-site peer 203.0.113.2 ikev2-reauth 'inherit' + set vpn ipsec site-to-site peer 203.0.113.2 local-address '10.10.0.5' + set vpn ipsec site-to-site peer 203.0.113.2 vti bind 'vti1' + set vpn ipsec site-to-site peer 203.0.113.2 vti esp-group 'AZURE' + +- **Important**: Add an interface route to reach Azure's BGP listener + +.. code-block:: none + + set protocols static interface-route 10.0.0.4/32 next-hop-interface vti1 + +- Configure your BGP settings + +.. code-block:: none + + set protocols bgp 64499 neighbor 10.0.0.4 remote-as '65540' + set protocols bgp 64499 neighbor 10.0.0.4 address-family ipv4-unicast soft-reconfiguration 'inbound' + set protocols bgp 64499 neighbor 10.0.0.4 timers holdtime '30' + set protocols bgp 64499 neighbor 10.0.0.4 timers keepalive '10' + +- **Important**: Disable connected check \ + +.. code-block:: none + + set protocols bgp 64499 neighbor 10.0.0.4 disable-connected-check diff --git a/docs/configexamples/azure-vpn-dual-bgp.rst b/docs/configexamples/azure-vpn-dual-bgp.rst new file mode 100644 index 00000000..13d4b5a2 --- /dev/null +++ b/docs/configexamples/azure-vpn-dual-bgp.rst @@ -0,0 +1,155 @@ +.. _examples-azure-vpn-dual-bgp: + +Route-Based Redundant Site-to-Site VPN to Azure (BGP over IKEv2/IPsec) +---------------------------------------------------------------------- + +This guide shows an example of a redundant (active-active) route-based IKEv2 +site-to-site VPN to Azure using VTI +and BGP for dynamic routing updates. + +Prerequisites +^^^^^^^^^^^^^ + +- A pair of Azure VNet Gateways deployed in active-active + configuration with BGP enabled. + +- A local network gateway deployed in Azure representing + the Vyos device, matching the below Vyos settings except for + address space, which only requires the Vyos private IP, in + this example 10.10.0.5/32 + +- A connection resource deployed in Azure linking the + Azure VNet gateway and the local network gateway representing + the Vyos device. + +Example +^^^^^^^ + ++---------------------------------------+---------------------+ +| WAN Interface | eth0 | ++---------------------------------------+---------------------+ +| On-premises address space | 10.10.0.0/16 | ++---------------------------------------+---------------------+ +| Azure address space | 10.0.0.0/16 | ++---------------------------------------+---------------------+ +| Vyos public IP | 198.51.100.3 | ++---------------------------------------+---------------------+ +| Vyos private IP | 10.10.0.5 | ++---------------------------------------+---------------------+ +| Azure VNet Gateway 1 public IP | 203.0.113.2 | ++---------------------------------------+---------------------+ +| Azure VNet Gateway 2 public IP | 203.0.113.3 | ++---------------------------------------+---------------------+ +| Azure VNet Gateway BGP IP | 10.0.0.4,10.0.0.5 | ++---------------------------------------+---------------------+ +| Pre-shared key | ch00s3-4-s3cur3-psk | ++---------------------------------------+---------------------+ +| Vyos ASN | 64499 | ++---------------------------------------+---------------------+ +| Azure ASN | 65540 | ++---------------------------------------+---------------------+ + +Vyos configuration +^^^^^^^^^^^^^^^^^^ + +- Configure the IKE and ESP settings to match a subset + of those supported by Azure: + +.. code-block:: none + + set vpn ipsec esp-group AZURE compression 'disable' + set vpn ipsec esp-group AZURE lifetime '3600' + set vpn ipsec esp-group AZURE mode 'tunnel' + set vpn ipsec esp-group AZURE pfs 'dh-group2' + set vpn ipsec esp-group AZURE proposal 1 encryption 'aes256' + set vpn ipsec esp-group AZURE proposal 1 hash 'sha1' + + set vpn ipsec ike-group AZURE dead-peer-detection action 'restart' + set vpn ipsec ike-group AZURE dead-peer-detection interval '15' + set vpn ipsec ike-group AZURE dead-peer-detection timeout '30' + set vpn ipsec ike-group AZURE ikev2-reauth 'yes' + set vpn ipsec ike-group AZURE key-exchange 'ikev2' + set vpn ipsec ike-group AZURE lifetime '28800' + set vpn ipsec ike-group AZURE proposal 1 dh-group '2' + set vpn ipsec ike-group AZURE proposal 1 encryption 'aes256' + set vpn ipsec ike-group AZURE proposal 1 hash 'sha1' + +- Enable IPsec on eth0 + +.. code-block:: none + + set vpn ipsec ipsec-interfaces interface 'eth0' + +- Configure two VTIs with a dummy IP address each + +.. code-block:: none + + set interfaces vti vti1 address '10.10.1.5/32' + set interfaces vti vti1 description 'Azure Primary Tunnel' + + set interfaces vti vti2 address '10.10.1.6/32' + set interfaces vti vti2 description 'Azure Secondary Tunnel' + +- Clamp the VTI's MSS to 1350 to avoid PMTU blackholes. + +.. code-block:: none + + set firewall options interface vti1 adjust-mss 1350 + set firewall options interface vti2 adjust-mss 1350 + +- Configure the VPN tunnels + +.. code-block:: none + + set vpn ipsec site-to-site peer 203.0.113.2 authentication id '198.51.100.3' + set vpn ipsec site-to-site peer 203.0.113.2 authentication mode 'pre-shared-secret' + set vpn ipsec site-to-site peer 203.0.113.2 authentication pre-shared-secret 'ch00s3-4-s3cur3-psk' + set vpn ipsec site-to-site peer 203.0.113.2 authentication remote-id '203.0.113.2' + set vpn ipsec site-to-site peer 203.0.113.2 connection-type 'respond' + set vpn ipsec site-to-site peer 203.0.113.2 description 'AZURE PRIMARY TUNNEL' + set vpn ipsec site-to-site peer 203.0.113.2 ike-group 'AZURE' + set vpn ipsec site-to-site peer 203.0.113.2 ikev2-reauth 'inherit' + set vpn ipsec site-to-site peer 203.0.113.2 local-address '10.10.0.5' + set vpn ipsec site-to-site peer 203.0.113.2 vti bind 'vti1' + set vpn ipsec site-to-site peer 203.0.113.2 vti esp-group 'AZURE' + + set vpn ipsec site-to-site peer 203.0.113.3 authentication id '198.51.100.3' + set vpn ipsec site-to-site peer 203.0.113.3 authentication mode 'pre-shared-secret' + set vpn ipsec site-to-site peer 203.0.113.3 authentication pre-shared-secret 'ch00s3-4-s3cur3-psk' + set vpn ipsec site-to-site peer 203.0.113.3 authentication remote-id '203.0.113.3' + set vpn ipsec site-to-site peer 203.0.113.3 connection-type 'respond' + set vpn ipsec site-to-site peer 203.0.113.3 description 'AZURE SECONDARY TUNNEL' + set vpn ipsec site-to-site peer 203.0.113.3 ike-group 'AZURE' + set vpn ipsec site-to-site peer 203.0.113.3 ikev2-reauth 'inherit' + set vpn ipsec site-to-site peer 203.0.113.3 local-address '10.10.0.5' + set vpn ipsec site-to-site peer 203.0.113.3 vti bind 'vti2' + set vpn ipsec site-to-site peer 203.0.113.3 vti esp-group 'AZURE' + +- **Important**: Add an interface route to reach both Azure's BGP listeners + +.. code-block:: none + + set protocols static interface-route 10.0.0.4/32 next-hop-interface vti1 + set protocols static interface-route 10.0.0.5/32 next-hop-interface vti2 + +- Configure your BGP settings + +.. code-block:: none + + set protocols bgp 64499 neighbor 10.0.0.4 remote-as '65540' + set protocols bgp 64499 neighbor 10.0.0.4 address-family ipv4-unicast soft-reconfiguration 'inbound' + set protocols bgp 64499 neighbor 10.0.0.4 timers holdtime '30' + set protocols bgp 64499 neighbor 10.0.0.4 timers keepalive '10' + + set protocols bgp 64499 neighbor 10.0.0.5 remote-as '65540' + set protocols bgp 64499 neighbor 10.0.0.5 address-family ipv4-unicast soft-reconfiguration 'inbound' + set protocols bgp 64499 neighbor 10.0.0.5 timers holdtime '30' + set protocols bgp 64499 neighbor 10.0.0.5 timers keepalive '10' + +- **Important**: Disable connected check, otherwise the routes learned + from Azure will not be imported into the routing table. + +.. code-block:: none + + set protocols bgp 64499 neighbor 10.0.0.4 disable-connected-check + set protocols bgp 64499 neighbor 10.0.0.5 disable-connected-check diff --git a/docs/configexamples/bgp-ipv6-unnumbered.rst b/docs/configexamples/bgp-ipv6-unnumbered.rst new file mode 100644 index 00000000..ccc1f69a --- /dev/null +++ b/docs/configexamples/bgp-ipv6-unnumbered.rst @@ -0,0 +1,172 @@ +.. _examples-bgp-ipv6-unnumbered: + +######################################### +BGP IPv6 unnumbered with extended nexthop +######################################### + +General information can be found in the :ref:`bgp` chapter. + +Configuration +============= + +- Router A: + +.. code-block:: none + + set protocols bgp 64496 address-family ipv4-unicast redistribute connected + set protocols bgp 64496 address-family ipv6-unicast redistribute connected + set protocols bgp 64496 neighbor eth1 interface v6only + set protocols bgp 64496 neighbor eth1 interface v6only peer-group 'fabric' + set protocols bgp 64496 neighbor eth2 interface v6only + set protocols bgp 64496 neighbor eth2 interface v6only peer-group 'fabric' + set protocols bgp 64496 parameters bestpath as-path multipath-relax + set protocols bgp 64496 parameters bestpath compare-routerid + set protocols bgp 64496 parameters default no-ipv4-unicast + set protocols bgp 64496 parameters router-id '192.168.0.1' + set protocols bgp 64496 peer-group fabric address-family ipv4-unicast + set protocols bgp 64496 peer-group fabric address-family ipv6-unicast + set protocols bgp 64496 peer-group fabric capability extended-nexthop + set protocols bgp 64496 peer-group fabric remote-as 'external' + +- Router B: + +.. code-block:: none + + set protocols bgp 64499 address-family ipv4-unicast redistribute connected + set protocols bgp 64499 address-family ipv6-unicast redistribute connected + set protocols bgp 64499 neighbor eth1 interface v6only + set protocols bgp 64499 neighbor eth1 interface v6only peer-group 'fabric' + set protocols bgp 64499 neighbor eth2 interface v6only + set protocols bgp 64499 neighbor eth2 interface v6only peer-group 'fabric' + set protocols bgp 64499 parameters bestpath as-path multipath-relax + set protocols bgp 64499 parameters bestpath compare-routerid + set protocols bgp 64499 parameters default no-ipv4-unicast + set protocols bgp 64499 parameters router-id '192.168.0.2' + set protocols bgp 64499 peer-group fabric address-family ipv4-unicast + set protocols bgp 64499 peer-group fabric address-family ipv6-unicast + set protocols bgp 64499 peer-group fabric capability extended-nexthop + set protocols bgp 64499 peer-group fabric remote-as 'external' + +Results +======= + +- Router A: + +.. code-block:: none + + vyos@vyos:~$ show interfaces + Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down + Interface IP Address S/L Description + --------- ---------- --- ----------- + eth0 198.51.100.34/24 u/u + eth1 - u/u + eth2 - u/u + lo 127.0.0.1/8 u/u + 192.168.0.1/32 + ::1/128 + +.. code-block:: none + + vyos@vyos:~$ show ip route + Codes: K - kernel route, C - connected, S - static, R - RIP, + O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, + T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, + F - PBR, f - OpenFabric, + > - selected route, * - FIB route + + S>* 0.0.0.0/0 [210/0] via 198.51.100.34, eth0, 03:21:53 + C>* 198.51.100.0/24 is directly connected, eth0, 03:21:53 + C>* 192.168.0.1/32 is directly connected, lo, 03:21:56 + B>* 192.168.0.2/32 [20/0] via fe80::a00:27ff:fe3b:7ed2, eth2, 00:05:07 + * via fe80::a00:27ff:fe7b:4000, eth1, 00:05:07 + +.. code-block:: none + + vyos@vyos:~$ ping 192.168.0.2 + PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data. + 64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=0.575 ms + 64 bytes from 192.168.0.2: icmp_seq=2 ttl=64 time=0.628 ms + 64 bytes from 192.168.0.2: icmp_seq=3 ttl=64 time=0.581 ms + 64 bytes from 192.168.0.2: icmp_seq=4 ttl=64 time=0.682 ms + 64 bytes from 192.168.0.2: icmp_seq=5 ttl=64 time=0.597 ms + + --- 192.168.0.2 ping statistics --- + 5 packets transmitted, 5 received, 0% packet loss, time 4086ms + rtt min/avg/max/mdev = 0.575/0.612/0.682/0.047 ms + +.. code-block:: none + + vyos@vyos:~$ show ip bgp summary + + IPv4 Unicast Summary: + BGP router identifier 192.168.0.1, local AS number 65020 vrf-id 0 + BGP table version 4 + RIB entries 5, using 800 bytes of memory + Peers 2, using 41 KiB of memory + Peer groups 1, using 64 bytes of memory + + Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd + eth1 4 64499 13 13 0 0 0 00:05:33 2 + eth2 4 64499 13 14 0 0 0 00:05:29 2 + + Total number of neighbors 2 + +- Router B: + +.. code-block:: none + + vyos@vyos:~$ show interfaces + Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down + Interface IP Address S/L Description + --------- ---------- --- ----------- + eth0 198.51.100.33/24 u/u + eth1 - u/u + eth2 - u/u + lo 127.0.0.1/8 u/u + 192.168.0.2/32 + ::1/128 + +.. code-block:: none + + vyos@vyos:~$ show ip route + Codes: K - kernel route, C - connected, S - static, R - RIP, + O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, + T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, + F - PBR, f - OpenFabric, + > - selected route, * - FIB route + + S>* 0.0.0.0/0 [210/0] via 198.51.100.33, eth0, 00:44:08 + C>* 198.51.100.0/24 is directly connected, eth0, 00:44:09 + B>* 192.168.0.1/32 [20/0] via fe80::a00:27ff:fe2d:205d, eth1, 00:06:18 + * via fe80::a00:27ff:fe93:e142, eth2, 00:06:18 + C>* 192.168.0.2/32 is directly connected, lo, 00:44:11 + +.. code-block:: none + + vyos@vyos:~$ ping 192.168.0.1 + PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data. + 64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=0.427 ms + 64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=0.471 ms + 64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=0.782 ms + 64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=0.715 ms + + --- 192.168.0.1 ping statistics --- + 4 packets transmitted, 4 received, 0% packet loss, time 3051ms + rtt min/avg/max/mdev = 0.427/0.598/0.782/0.155 ms + +.. code-block:: none + + vyos@vyos:~$ show ip bgp summary + IPv4 Unicast Summary: + BGP router identifier 192.168.0.2, local AS number 65021 vrf-id 0 + BGP table version 4 + RIB entries 5, using 800 bytes of memory + Peers 2, using 41 KiB of memory + Peer groups 1, using 64 bytes of memory + + Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd + eth1 4 64496 14 14 0 0 0 00:06:40 2 + eth2 4 64496 14 14 0 0 0 00:06:37 2 + + Total number of neighbors 2 + diff --git a/docs/configexamples/dhcp-relay-through-gre-bridge.rst b/docs/configexamples/dhcp-relay-through-gre-bridge.rst new file mode 100644 index 00000000..f94eb67f --- /dev/null +++ b/docs/configexamples/dhcp-relay-through-gre-bridge.rst @@ -0,0 +1,77 @@ +.. _examples-dhcp-relay-through-gre-bridge: + + +DHCP Relay through GRE-Bridge +----------------------------- + +Diagram +^^^^^^^ + +.. image:: /_static/images/dhcp-relay-through-gre-bridge.png + :width: 80% + :align: center + :alt: Network Topology Diagram + +Configuration +^^^^^^^^^^^^^ + +DHCP Server +""""""""""" + +.. code-block:: none + + set interfaces ethernet eth0 address '10.0.2.1/24' + set interfaces loopback lo address '3.3.3.3/24' + set interfaces tunnel tun100 address '172.16.0.2/30' + set interfaces tunnel tun100 encapsulation 'gre-bridge' + set interfaces tunnel tun100 local-ip '10.0.2.1' + set interfaces tunnel tun100 remote-ip '192.168.0.1' + set protocols ospf area 0 network '3.3.3.0/24' + set protocols ospf area 0 network '10.0.2.0/24' + set protocols ospf parameters router-id '3.3.3.3' + set protocols static interface-route 10.0.1.2/32 next-hop-interface tun100 + set service dhcp-server shared-network-name asdf authoritative + set service dhcp-server shared-network-name asdf subnet 3.3.3.0/24 range 0 start '3.3.3.30' + set service dhcp-server shared-network-name asdf subnet 3.3.3.0/24 range 0 stop '3.3.3.40' + set service dhcp-server shared-network-name asdf subnet 10.0.1.0/24 default-router '10.0.1.2' + set service dhcp-server shared-network-name asdf subnet 10.0.1.0/24 range 0 start '10.0.1.200' + set service dhcp-server shared-network-name asdf subnet 10.0.1.0/24 range 0 stop '10.0.1.210' + set service dhcp-server shared-network-name asdf subnet 10.2.1.0/24 range 0 start '10.2.1.222' + set service dhcp-server shared-network-name asdf subnet 10.2.1.0/24 range 0 stop '10.2.1.233' + set service dhcp-server shared-network-name asdf subnet 172.16.0.0/30 range 0 start '172.16.0.1' + set service dhcp-server shared-network-name asdf subnet 172.16.0.0/30 range 0 stop '172.16.0.2' + + +In-Between Router +""""""""""""""""" + +.. code-block:: none + + set interfaces ethernet eth0 address '192.168.0.2/24' + set interfaces ethernet eth1 address '10.0.2.2/24' + set protocols ospf area 0 network '192.168.0.0/24' + set protocols ospf area 0 network '10.0.2.0/24' + set protocols ospf parameters router-id '192.168.0.2' + + +DHCP Relay +"""""""""" + +.. code-block:: none + + set interfaces ethernet eth0 address '10.0.1.2/24' + set interfaces ethernet eth1 address '192.168.0.1/24' + set interfaces loopback lo address '1.1.1.1' + set interfaces tunnel tun100 address '172.16.0.1/30' + set interfaces tunnel tun100 encapsulation 'gre-bridge' + set interfaces tunnel tun100 local-ip '192.168.0.1' + set interfaces tunnel tun100 remote-ip '10.0.2.1' + set protocols ospf area 0 network '10.0.1.0/24' + set protocols ospf area 0 network '192.168.0.0/24' + set protocols ospf area 0 network '1.1.1.0/24' + set protocols ospf parameters router-id '1.1.1.1' + set protocols static interface-route 3.3.3.3/32 next-hop-interface tun100 + set service dhcp-relay interface 'eth0' + set service dhcp-relay interface 'tun100' + set service dhcp-relay server '3.3.3.3' + diff --git a/docs/configexamples/ha.rst b/docs/configexamples/ha.rst new file mode 100644 index 00000000..702cb2b2 --- /dev/null +++ b/docs/configexamples/ha.rst @@ -0,0 +1,580 @@ +############################# +High Availability Walkthrough +############################# + +This document walks you through a complete HA setup of two VyOS machines. This +design is based on a VM as the primary router, and a physical machine as a +backup, using VRRP, BGP, OSPF and conntrack sharing. + +The aim of this document is to walk you through setting everything up so you +and up at a point where you can reboot any machine and not lose more than a few +seconds worth of connectivity. + +Design +====== + +This is based on a real life, in production design. One of the complex issues +is ensuring you have redundant data INTO your network. We do this with a pair +of Cisco Nexus switches, and using Virtual PortChannels that are spanned across +them. This as an added bonus, also allows for complete switch failure without +an outage. How you achieve this yourself is left as an exercise to the reader +but our setup is documented here. + +Walkthrough suggestion +---------------------- + +The ``commit`` command is implied after every section. If you make an error, +``commit`` will warn you and you can fix it before getting too far into things. +Please ensure you commit early and commit often. + +If you are following through this document, it is strongly suggested you +complete the entire document, ONLY doing the virtual router1 steps, and then +come back and walk through it AGAIN on the backup hardware router. + +This ensures you don't go to fast, or miss a step. However, it will make your +life easier to configure the fixed IP address and default route now on the +hardware router. + +Example Network +--------------- + +In this document, we have been allocated 203.0.113.0/24 by our upstream +provider, which we are publishing on VLAN100. + +They want us to establish a BGP session to their routers on 192.0.2.11 and +192.0.2.12 from our routers 192.0.2.21 and 192.0.2.22. They are AS 65550 and +we are AS65551. + +Our routers are going to have a floating IP address of 203.0.113.1, and use +.2 and .3 as their fixed IPs. + +We are going to use 10.200.201.0/24 for an 'internal' network on VLAN201. + +When traffic is originated from the 10.200.201.0/24 network, it will be +masqueraded to 203.0.113.1 + +For connection between sites, we are running a WireGuard link to two REMOTE +routers, and using OSPF over those links to distribute routes. That remote +site is expected to send traffic from anything in 10.201.0.0/16 + +VLANs +----- + +These are the vlans we wll be using: + +* 50: Upstream, using the 192.0.2.0/24 network allocated by them. +* 100: 'Public' network, using our 203.0.113.0/24 network. +* 201: 'Internal' network, using 10.200.201.0/24 + +Hardware +-------- + +* switch1 (Nexus 10gb Switch) +* switch2 (Nexus 10gb Switch) +* compute1 (VMware ESXi 6.5) +* compute2 (VMware ESXi 6.5) +* compute3 (VMware ESXi 6.5) +* router2 (Random 1RU machine with 4 NICs) + +Note that router1 is a VM that runs on one of the compute nodes. + +Network Cabling +--------------- + +* From Datacenter - This connects into port 1 on both switches, and is tagged + as VLAN 50 +* Cisco VPC Crossconnect - Ports 39 and 40 bonded between each switch +* Hardware Router - Port 8 of each switch +* compute1 - Port 9 of each switch +* compute2 - Port 10 of each switch +* compute3 - Port 11 of each switch + +This is ignoring the extra Out-of-band management networking, which should be +on totally different switches, and a different feed into the rack, and is out +of scope of this. + +.. note:: Our implementation uses VMware's Distributed Port Groups, which allows + VMware to use LACP. This is a part of the ENTERPRISE licence, and is not + available on a Free licence. If you are implementing this and do not have + access to DPGs, you should not use VMware, and use some other virtualization + platform instead. + + +Basic Setup (via console) +========================= + +Create your router1 VM so it is able to withstand a VM Host failing, or a +network link failing. Using VMware, this is achieved by enabling vSphere DRS, +vSphere Availability, and creating a Distributed Port Group that uses LACP. + +Many other Hypervisors do this, and I'm hoping that this document will be +expanded to document how to do this for others. + +Create an 'All VLANs' network group, that passes all trunked traffic through +to the VM. Attach this network group to router1 as eth0. + +.. note:: VMware: You must DISABLE SECURITY on this Port group. Make sure that + ``Promiscuous Mode``\ , ``MAC address changes`` and ``Forged transmits`` are + enabled. All of these will be done as part of failover. + +Bonding on Hardware Router +-------------------------- + +Create a LACP bond on the hardware router. We are assuming that eth0 and eth1 +are connected to port 8 on both switches, and that those ports are configured +as a Port-Channel. + +.. code-block:: none + + set interfaces bonding bond0 description 'Switch Port-Channel' + set interfaces bonding bond0 hash-policy 'layer2' + set interfaces bonding bond0 member interface 'eth0' + set interfaces bonding bond0 member interface 'eth1' + set interfaces bonding bond0 mode '802.3ad' + + +Assign external IP addresses +---------------------------- + +VLAN 100 and 201 will have floating IP addresses, but VLAN50 does not, as this +is talking directly to upstream. Create our IP address on vlan50. + +For the hardware router, replace ``eth0`` with ``bond0``. As (almost) every +command is identical, this will not be specified unless different things need +to be performed on different hosts. + +.. code-block:: none + + set interfaces ethernet eth0 vif 50 address '192.0.2.21/24' + +In this case, the hardware router has a different IP, so it would be + +.. code-block:: none + + set interfaces ethernet bond0 vif 50 address '192.0.2.22/24' + +Add (temporary) default route +----------------------------- + +It is assumed that the routers provided by upstream are capable of acting as a +default router, add that as a static route. + +.. code-block:: none + + set protocols static route 0.0.0.0/0 next-hop 192.0.2.11 + commit + save + + +Enable SSH +---------- + +Enable SSH so you can now SSH into the routers, rather than using the console. + +.. code-block:: none + + set service ssh + commit + save + +At this point you should be able to SSH into both of them, and will no longer +need access to the console (unless you break something!) + + +VRRP Configuration +================== + +We are setting up VRRP so that it does NOT fail back when a machine returns into +service, and it prioritizes router1 over router2. + +Internal Network +---------------- + +This has a floating IP address of 10.200.201.1/24, using virtual router ID 201. +The difference between them is the interface name, hello-source-address, and +peer-address. + +**router1** + +.. code-block:: none + + set interfaces ethernet eth0 vif 201 address 10.200.201.2/24 + set high-availability vrrp group int hello-source-address '10.200.201.2' + set high-availability vrrp group int interface 'eth0.201' + set high-availability vrrp group int peer-address '10.200.201.3' + set high-availability vrrp group int no-preempt + set high-availability vrrp group int priority '200' + set high-availability vrrp group int virtual-address '10.200.201.1/24' + set high-availability vrrp group int vrid '201' + + +**router2** + +.. code-block:: none + + set interfaces ethernet bond0 vif 201 address 10.200.201.3/24 + set high-availability vrrp group int hello-source-address '10.200.201.3' + set high-availability vrrp group int interface 'bond0.201' + set high-availability vrrp group int peer-address '10.200.201.2' + set high-availability vrrp group int no-preempt + set high-availability vrrp group int priority '100' + set high-availability vrrp group int virtual-address '10.200.201.1/24' + set high-availability vrrp group int vrid '201' + + +Public Network +-------------- + +This has a floating IP address of 203.0.113.1/24, using virtual router ID 113. +The virtual router ID is just a random number between 1 and 254, and can be set +to whatever you want. Best practices suggest you try to keep them unique +enterprise-wide. + +**router1** + +.. code-block:: none + + set interfaces ethernet eth0 vif 100 address 203.0.113.2/24 + set high-availability vrrp group public hello-source-address '203.0.113.2' + set high-availability vrrp group public interface 'eth0.100' + set high-availability vrrp group public peer-address '203.0.113.3' + set high-availability vrrp group public no-preempt + set high-availability vrrp group public priority '200' + set high-availability vrrp group public virtual-address '203.0.113.1/24' + set high-availability vrrp group public vrid '113' + +**router2** + +.. code-block:: none + + set interfaces ethernet bond0 vif 100 address 203.0.113.3/24 + set high-availability vrrp group public hello-source-address '203.0.113.3' + set high-availability vrrp group public interface 'bond0.100' + set high-availability vrrp group public peer-address '203.0.113.2' + set high-availability vrrp group public no-preempt + set high-availability vrrp group public priority '100' + set high-availability vrrp group public virtual-address '203.0.113.1/24' + set high-availability vrrp group public vrid '113' + + +Create VRRP sync-group +---------------------- + +The sync group is used to replicate connection tracking. It needs to be assigned +to a random VRRP group, and we are creating a sync group called ``sync`` using +the vrrp group ``int``. + +.. code-block:: none + + set high-availability vrrp sync-group sync member 'int' + +Testing +------- + +At this point, you should be able to see both IP addresses when you run +``show interfaces``\ , and ``show vrrp`` should show both interfaces in MASTER +state (and SLAVE state on router2). + +.. code-block:: none + + vyos@router1:~$ show vrrp + Name Interface VRID State Last Transition + -------- ----------- ------ ------- ----------------- + int eth0.201 201 MASTER 100s + public eth0.100 113 MASTER 200s + vyos@router1:~$ + + +You should be able to ping to and from all the IPs you have allocated. + +NAT and conntrack-sync +====================== + +Masquerade Traffic originating from 10.200.201.0/24 that is heading out the +public interface. + +.. note:: We explicitly exclude the primary upstream network so that BGP or + OSPF traffic doesn't accidentally get NAT'ed. + +.. code-block:: none + + set nat source rule 10 destination address '!192.0.2.0/24' + set nat source rule 10 outbound-interface 'eth0.50' + set nat source rule 10 source address '10.200.201.0/24' + set nat source rule 10 translation address '203.0.113.1' + + +Configure conntrack-sync and disable helpers +-------------------------------------------- + +Most conntrack modules cause more problems than they're worth, especially in a +complex network. Turn them off by default, and if you need to turn them on +later, you can do so. + +.. code-block:: none + + set system conntrack modules ftp disable + set system conntrack modules gre disable + set system conntrack modules nfs disable + set system conntrack modules pptp disable + set system conntrack modules sip disable + set system conntrack modules tftp disable + +Now enable replication between nodes. Replace eth0.201 with bond0.201 on the +hardware router. + +.. code-block:: none + + set service conntrack-sync accept-protocol 'tcp,udp,icmp' + set service conntrack-sync event-listen-queue-size '8' + set service conntrack-sync failover-mechanism vrrp sync-group 'sync' + set service conntrack-sync interface eth0.201 + set service conntrack-sync mcast-group '224.0.0.50' + set service conntrack-sync sync-queue-size '8' + +Testing +------- + +The simplest way to test is to look at the connection tracking stats on the +standby hardware router with the command ``show conntrack-sync statistics``. +The numbers should be very close to the numbers on the primary router. + +When you have both routers up, you should be able to establish a connection +from a NAT'ed machine out to the internet, reboot the active machine, and that +connection should be preserved, and will not drop out. + +OSPF Over WireGuard +=================== + +Wireguard doesn't have the concept of an up or down link, due to its design. +This complicates AND simplifies using it for network transport, as for reliable +state detection you need to use SOMETHING to detect when the link is down. + +If you use a routing protocol itself, you solve two problems at once. This is +only a basic example, and is provided as a starting point. + +Configure Wireguard +------------------- + +There is plenty of instructions and documentation on setting up Wireguard. The +only important thing you need to remember is to only use one WireGuard +interface per OSPF connection. + +We use small /30's from 10.254.60/24 for the point-to-point links. + +**router1** + +Replace the 203.0.113.3 with whatever the other router's IP address is. + +.. code-block:: none + + set interfaces wireguard wg01 address '10.254.60.1/30' + set interfaces wireguard wg01 description 'router1-to-offsite1' + set interfaces wireguard wg01 ip ospf authentication md5 key-id 1 md5-key 'i360KoCwUGZvPq7e' + set interfaces wireguard wg01 ip ospf cost '11' + set interfaces wireguard wg01 ip ospf dead-interval '5' + set interfaces wireguard wg01 ip ospf hello-interval '1' + set interfaces wireguard wg01 ip ospf network 'point-to-point' + set interfaces wireguard wg01 ip ospf priority '1' + set interfaces wireguard wg01 ip ospf retransmit-interval '5' + set interfaces wireguard wg01 ip ospf transmit-delay '1' + set interfaces wireguard wg01 peer OFFSITE1 allowed-ips '0.0.0.0/0' + set interfaces wireguard wg01 peer OFFSITE1 endpoint '203.0.113.3:50001' + set interfaces wireguard wg01 peer OFFSITE1 persistent-keepalive '15' + set interfaces wireguard wg01 peer OFFSITE1 pubkey 'GEFMOWzAyau42/HwdwfXnrfHdIISQF8YHj35rOgSZ0o=' + set interfaces wireguard wg01 port '50001' + + +**offsite1** + +This is connecting back to the STATIC IP of router1, not the floating. + +.. code-block:: none + + set interfaces wireguard wg01 address '10.254.60.2/30' + set interfaces wireguard wg01 description 'offsite1-to-router1' + set interfaces wireguard wg01 ip ospf authentication md5 key-id 1 md5-key 'i360KoCwUGZvPq7e' + set interfaces wireguard wg01 ip ospf cost '11' + set interfaces wireguard wg01 ip ospf dead-interval '5' + set interfaces wireguard wg01 ip ospf hello-interval '1' + set interfaces wireguard wg01 ip ospf network 'point-to-point' + set interfaces wireguard wg01 ip ospf priority '1' + set interfaces wireguard wg01 ip ospf retransmit-interval '5' + set interfaces wireguard wg01 ip ospf transmit-delay '1' + set interfaces wireguard wg01 peer ROUTER1 allowed-ips '0.0.0.0/0' + set interfaces wireguard wg01 peer ROUTER1 endpoint '192.0.2.21:50001' + set interfaces wireguard wg01 peer ROUTER1 persistent-keepalive '15' + set interfaces wireguard wg01 peer ROUTER1 pubkey 'CKwMV3ZaLntMule2Kd3G7UyVBR7zE8/qoZgLb82EE2Q=' + set interfaces wireguard wg01 port '50001' + +Test WireGuard +-------------- + +Make sure you can ping 10.254.60.1 and .2 from both routers. + +Create Export Filter +-------------------- + +We only want to export the networks we know we should be exporting. Always +whitelist your route filters, both importing and exporting. A good rule of +thumb is **'If you are not the default router for a network, don't advertise +it'**. This means we explicitly do not want to advertise the 192.0.2.0/24 +network (but do want to advertise 10.200.201.0 and 203.0.113.0, which we ARE +the default route for). This filter is applied to ``redistribute connected``. +If we WERE to advertise it, the remote machines would see 192.0.2.21 available +via their default route, establish the connection, and then OSPF would say +'192.0.2.0/24 is available via this tunnel', at which point the tunnel would +break, OSPF would drop the routes, and then 192.0.2.0/24 would be reachable via +default again. This is called 'flapping'. + +.. code-block:: none + + set policy access-list 150 description 'Outbound OSPF Redistribution' + set policy access-list 150 rule 10 action 'permit' + set policy access-list 150 rule 10 destination any + set policy access-list 150 rule 10 source inverse-mask '0.0.0.255' + set policy access-list 150 rule 10 source network '10.200.201.0' + set policy access-list 150 rule 20 action 'permit' + set policy access-list 150 rule 20 destination any + set policy access-list 150 rule 20 source inverse-mask '0.0.0.255' + set policy access-list 150 rule 20 source network '203.0.113.0' + set policy access-list 150 rule 100 action 'deny' + set policy access-list 150 rule 100 destination any + set policy access-list 150 rule 100 source any + + +Create Import Filter +-------------------- + +We only want to import networks we know about. Our OSPF peer should only be +advertising networks in the 10.201.0.0/16 range. Note that this is an INVERSE +MATCH. You deny in access-list 100 to accept the route. + +.. code-block:: none + + set policy access-list 100 description 'Inbound OSPF Routes from Peers' + set policy access-list 100 rule 10 action 'deny' + set policy access-list 100 rule 10 destination any + set policy access-list 100 rule 10 source inverse-mask '0.0.255.255' + set policy access-list 100 rule 10 source network '10.201.0.0' + set policy access-list 100 rule 100 action 'permit' + set policy access-list 100 rule 100 destination any + set policy access-list 100 rule 100 source any + set policy route-map PUBOSPF rule 100 action 'deny' + set policy route-map PUBOSPF rule 100 match ip address access-list '100' + set policy route-map PUBOSPF rule 500 action 'permit' + + +Enable OSPF +----------- + +Every router **must** have a unique router-id. +The 'reference-bandwidth' is used because when OSPF was originally designed, +the idea of a link faster than 1gbit was unheard of, and it does not scale +correctly. + +.. code-block:: none + + set protocols ospf area 0.0.0.0 authentication 'md5' + set protocols ospf area 0.0.0.0 network '10.254.60.0/24' + set protocols ospf auto-cost reference-bandwidth '10000' + set protocols ospf log-adjacency-changes + set protocols ospf parameters abr-type 'cisco' + set protocols ospf parameters router-id '10.254.60.2' + set protocols ospf route-map PUBOSPF + + +Test OSPF +--------- + +When you have enabled OSPF on both routers, you should be able to see each +other with the command ``show ip ospf neighbour``. The state must be 'Full' +or '2-Way', if it is not then there is a network connectivity issue between the +hosts. This is often caused by NAT or MTU issues. You should not see any new +routes (unless this is the second pass) in the output of ``show ip route`` + +Advertise connected routes +========================== + +As a reminder, only advertise routes that you are the default router for. This +is why we are NOT announcing the 192.0.2.0/24 network, because if that was +announced into OSPF, the other routers would try to connect to that network +over a tunnel that connects to that network! + +.. code-block:: none + + set protocols ospf access-list 150 export 'connected' + set protocols ospf redistribute connected + + +You should now be able to see the advertised network on the other host. + +Duplicate configuration +----------------------- + +At this pont you now need to create the X link between all four routers. Use a +different /30 for each link. + +Priorities +---------- + +Set the cost on the secondary links to be 200. This means that they will not +be used unless the primary links are down. + +.. code-block:: none + + set interfaces wireguard wg01 ip ospf cost '10' + set interfaces wireguard wg02 ip ospf cost '200' + + +This will be visible in 'show ip route'. + +BGP +=== + +BGP is an extremely complex network protocol. An example is provided here. + +.. note:: Router id's must be unique. + +**router1** + + +The ``redistribute ospf`` command is there purely as an example of how this can +be expanded. In this walkthrough, it will be filtered by BGPOUT rule 10000, as +it is not 203.0.113.0/24. + +.. code-block:: none + + set policy prefix-list BGPOUT description 'BGP Export List' + set policy prefix-list BGPOUT rule 10 action 'deny' + set policy prefix-list BGPOUT rule 10 description 'Do not advertise short masks' + set policy prefix-list BGPOUT rule 10 ge '25' + set policy prefix-list BGPOUT rule 10 prefix '0.0.0.0/0' + set policy prefix-list BGPOUT rule 100 action 'permit' + set policy prefix-list BGPOUT rule 100 description 'Our network' + set policy prefix-list BGPOUT rule 100 prefix '203.0.113.0/24' + set policy prefix-list BGPOUT rule 10000 action 'deny' + set policy prefix-list BGPOUT rule 10000 prefix '0.0.0.0/0' + set policy route-map BGPOUT description 'BGP Export Filter' + set policy route-map BGPOUT rule 10 action 'permit' + set policy route-map BGPOUT rule 10 match ip address prefix-list 'BGPOUT' + set policy route-map BGPOUT rule 10000 action 'deny' + set policy route-map BGPPREPENDOUT description 'BGP Export Filter' + set policy route-map BGPPREPENDOUT rule 10 action 'permit' + set policy route-map BGPPREPENDOUT rule 10 set as-path-prepend '65551 65551 65551' + set policy route-map BGPPREPENDOUT rule 10 match ip address prefix-list 'BGPOUT' + set policy route-map BGPPREPENDOUT rule 10000 action 'deny' + set protocols bgp 65551 address-family ipv4-unicast network 192.0.2.0/24 + set protocols bgp 65551 address-family ipv4-unicast redistribute connected metric '50' + set protocols bgp 65551 address-family ipv4-unicast redistribute ospf metric '50' + set protocols bgp 65551 neighbor 192.0.2.11 address-family ipv4-unicast route-map export 'BGPOUT' + set protocols bgp 65551 neighbor 192.0.2.11 address-family ipv4-unicast soft-reconfiguration inbound + set protocols bgp 65551 neighbor 192.0.2.11 remote-as '65550' + set protocols bgp 65551 neighbor 192.0.2.11 update-source '192.0.2.21' + set protocols bgp 65551 parameters router-id '192.0.2.21' + + +**router2** + +This is identical, but you use the BGPPREPENDOUT route-map to advertise the +route with a longer path. diff --git a/docs/configexamples/index.rst b/docs/configexamples/index.rst new file mode 100644 index 00000000..b2f7bfde --- /dev/null +++ b/docs/configexamples/index.rst @@ -0,0 +1,19 @@ +.. _examples: + +Configuration Blueprints +======================== + +This chapter contains various configuration examples: + +.. toctree:: + :maxdepth: 2 + + dhcp-relay-through-gre-bridge + zone-policy + bgp-ipv6-unnumbered + ospf-unnumbered + azure-vpn-bgp + azure-vpn-dual-bgp + tunnelbroker-ipv6 + ha + wan-load-balancing diff --git a/docs/configexamples/ospf-unnumbered.rst b/docs/configexamples/ospf-unnumbered.rst new file mode 100644 index 00000000..39f8f69a --- /dev/null +++ b/docs/configexamples/ospf-unnumbered.rst @@ -0,0 +1,118 @@ +.. _examples-ospf-unnumbered: + +######################### +OSPF unnumbered with ECMP +######################### + +General infomration can be found in the :ref:`routing-ospf` chapter. + +Configuration +============= + +- Router A: + +.. code-block:: none + + set interfaces ethernet eth0 address '10.0.0.1/24' + set interfaces ethernet eth1 address '192.168.0.1/32' + set interfaces ethernet eth1 ip ospf authentication md5 key-id 1 md5-key 'yourpassword' + set interfaces ethernet eth1 ip ospf network 'point-to-point' + set interfaces ethernet eth2 address '192.168.0.1/32' + set interfaces ethernet eth2 ip ospf authentication md5 key-id 1 md5-key 'yourpassword' + set interfaces ethernet eth2 ip ospf network 'point-to-point' + set interfaces loopback lo address '192.168.0.1/32' + set protocols ospf area 0.0.0.0 authentication 'md5' + set protocols ospf area 0.0.0.0 network '192.168.0.1/32' + set protocols ospf parameters router-id '192.168.0.1' + set protocols ospf redistribute connected + +- Router B: + +.. code-block:: none + + set interfaces ethernet eth0 address '10.0.0.2/24' + set interfaces ethernet eth1 address '192.168.0.2/32' + set interfaces ethernet eth1 ip ospf authentication md5 key-id 1 md5-key 'yourpassword' + set interfaces ethernet eth1 ip ospf network 'point-to-point' + set interfaces ethernet eth2 address '192.168.0.2/32' + set interfaces ethernet eth2 ip ospf authentication md5 key-id 1 md5-key 'yourpassword' + set interfaces ethernet eth2 ip ospf network 'point-to-point' + set interfaces loopback lo address '192.168.0.2/32' + set protocols ospf area 0.0.0.0 authentication 'md5' + set protocols ospf area 0.0.0.0 network '192.168.0.2/32' + set protocols ospf parameters router-id '192.168.0.2' + set protocols ospf redistribute connected + + +Results +======= + +- Router A: + +.. code-block:: none + + vyos@vyos:~$ show interfaces + Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down + Interface IP Address S/L Description + --------- ---------- --- ----------- + eth0 10.0.0.1/24 u/u + eth1 192.168.0.1/32 u/u + eth2 192.168.0.1/32 u/u + lo 127.0.0.1/8 u/u + 192.168.0.1/32 + ::1/128 + +.. code-block:: none + + vyos@vyos:~$ show ip route + Codes: K - kernel route, C - connected, S - static, R - RIP, + O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, + T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, + F - PBR, f - OpenFabric, + > - selected route, * - FIB route, q - queued route, r - rejected route + + S>* 0.0.0.0/0 [210/0] via 10.0.0.254, eth0, 00:57:34 + O 10.0.0.0/24 [110/20] via 192.168.0.2, eth1 onlink, 00:13:21 + via 192.168.0.2, eth2 onlink, 00:13:21 + C>* 10.0.0.0/24 is directly connected, eth0, 00:57:35 + O 192.168.0.1/32 [110/0] is directly connected, lo, 00:48:53 + C * 192.168.0.1/32 is directly connected, eth2, 00:56:31 + C * 192.168.0.1/32 is directly connected, eth1, 00:56:31 + C>* 192.168.0.1/32 is directly connected, lo, 00:57:36 + O>* 192.168.0.2/32 [110/1] via 192.168.0.2, eth1 onlink, 00:29:03 + * via 192.168.0.2, eth2 onlink, 00:29:03 + +- Router B: + +.. code-block:: none + + vyos@vyos:~$ show interfaces + Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down + Interface IP Address S/L Description + --------- ---------- --- ----------- + eth0 10.0.0.2/24 u/u + eth1 192.168.0.2/32 u/u + eth2 192.168.0.2/32 u/u + lo 127.0.0.1/8 u/u + 192.168.0.2/32 + ::1/128 + +.. code-block:: none + + vyos@vyos:~$ show ip route + Codes: K - kernel route, C - connected, S - static, R - RIP, + O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, + T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, + F - PBR, f - OpenFabric, + > - selected route, * - FIB route, q - queued route, r - rejected route + + S>* 0.0.0.0/0 [210/0] via 10.0.0.254, eth0, 00:57:34 + O 10.0.0.0/24 [110/20] via 192.168.0.1, eth1 onlink, 00:13:21 + via 192.168.0.1, eth2 onlink, 00:13:21 + C>* 10.0.0.0/24 is directly connected, eth0, 00:57:35 + O 192.168.0.2/32 [110/0] is directly connected, lo, 00:48:53 + C * 192.168.0.2/32 is directly connected, eth2, 00:56:31 + C * 192.168.0.2/32 is directly connected, eth1, 00:56:31 + C>* 192.168.0.2/32 is directly connected, lo, 00:57:36 + O>* 192.168.0.1/32 [110/1] via 192.168.0.1, eth1 onlink, 00:29:03 + * via 192.168.0.1, eth2 onlink, 00:29:03 diff --git a/docs/configexamples/tunnelbroker-ipv6.rst b/docs/configexamples/tunnelbroker-ipv6.rst new file mode 100644 index 00000000..868b225f --- /dev/null +++ b/docs/configexamples/tunnelbroker-ipv6.rst @@ -0,0 +1,169 @@ +.. _examples-tunnelbroker-ipv6: + +####################### +Tunnelbroker.net (IPv6) +####################### + +This guides walks through the setup of https://www.tunnelbroker.net/ for an +IPv6 Tunnel. + +Prerequisites +============= + +- A public, routable IPv4 address. This does not necessarily need to be static, + but you will need to update the tunnel endpoint when/if your IP address + changes, which can be done with a script and a scheduled task. +- Account at https://www.tunnelbroker.net/ +- Requested a "Regular Tunnel". You want to choose a location that is closest + to your physical location for the best response time. + +Setup initial tunnel +==================== + +Set up initial IPv6 tunnel. Replace the field below from the fields on the +tunnel information page. + +.. code-block:: none + + conf + set interfaces tunnel tun0 address Client_IPv6_from_Tunnelbroker # This will be your VyOS install's public IPv6 address + set interfaces tunnel tun0 description 'HE.NET IPv6 Tunnel' + set interfaces tunnel tun0 encapsulation 'sit' + set interfaces tunnel tun0 local-ip Client_IPv4_from_Tunnelbroker # This is your public IP + set interfaces tunnel tun0 mtu '1472' + set interfaces tunnel tun0 multicast 'disable' + set interfaces tunnel tun0 remote-ip Server_IPv4_from_Tunnelbroker # This is the IP of the Tunnelbroker server + set protocols static interface-route6 ::/0 next-hop-interface tun0 # Tell all traffic to go over this tunnel + commit + +If your WAN connection is over PPPoE, you may need to set the MTU on the above +tunnel lower than 1472. + +At this point you should be able to ping an IPv6 address, try pinging Google: + +.. code-block:: none + + ping6 -c2 2001:4860:4860::8888 + + 64 bytes from 2001:4860:4860::8888: icmp_seq=1 ttl=57 time=21.7 ms + 64 bytes from 2001:4860:4860::8888: icmp_seq=2 ttl=57 time=21.1 ms + + --- 2001:4860:4860::8888 ping statistics --- + 2 packets transmitted, 2 received, 0% packet loss, time 1001ms + rtt min/avg/max/mdev = 21.193/21.459/21.726/0.304 ms + +Assuming the pings are successful, you need to add some DNS servers. +Some options: + +.. code-block:: none + + set system name-server 2001:4860:4860::8888 # Google + set system name-server 2001:4860:4860::8844 # Google + set system name-server 2606:4700:4700::1111 # Cloudflare + set system name-server 2606:4700:4700::1001 # Cloudflare + commit + +You should now be able to ping something by IPv6 DNS name: + +.. code-block:: none + + # ping6 -c2 one.one.one.one + PING one.one.one.one(one.one.one.one) 56 data bytes + 64 bytes from one.one.one.one: icmp_seq=1 ttl=58 time=16.8 ms + 64 bytes from one.one.one.one: icmp_seq=2 ttl=58 time=17.4 ms + + --- one.one.one.one ping statistics --- + 2 packets transmitted, 2 received, 0% packet loss, time 1001ms + rtt min/avg/max/mdev = 16.880/17.153/17.426/0.273 ms + +Assuming everything works, you can proceed to client configuration + +LAN Configuration +================= + +At this point your VyOS install should have full IPv6, but now your LAN devices +need access. + +With Tunnelbroker.net, you have two options: + +- Routed /64. This is the default assignment. In IPv6-land, it's good for a + single "LAN", and is somewhat equivalent to a /24. + Example: `2001:470:xxxx:xxxx::/64` +- Routed /48. This is something you can request by clicking the "Assign /48" + link in the Tunnelbroker.net tunnel config. It allows you to have up to 65k + LANs. Example: `2001:470:xxxx::/48` + +Unlike IPv4, IPv6 is really not designed to be broken up smaller than /64. So +if you ever want to have multiple LANs, VLANs, DMZ, etc, you'll want to ignore +the assigned /64, and request the /48 and use that. + +Single LAN Setup +================ + +Single LAN setup where eth1 is your LAN interface. Use the /64 (all the xxxx +should be replaced with the information from your `Routed /64` tunnel): + +.. code-block:: none + + set interfaces ethernet eth1 address '2001:470:xxxx:xxxx::1/64' + set service router-advert interface eth1 name-server '2001:4860:4860::8888' + set service router-advert interface eth1 name-server '2001:4860:4860::8844' + set service router-advert interface eth1 prefix 2001:470:xxxx:xxxx::/64 + +Please note, 'autonomous-flag' and 'on-link-flag' are enabled by default, 'valid-lifetime' and 'preferred-lifetime' are set to default values of 30 days and 4 hours respectively. + +This accomplishes a few things: + +- Sets your LAN interface's IP address +- Enables router advertisements. This is an IPv6 alternative for DHCP (though + DHCPv6 can still be used). With RAs, Your devices will automatically find the + information they need for routing and DNS. + +Multiple LAN/DMZ Setup +====================== + +In this, you use the `Routed /48` information. This allows you to assign a +different /64 to every interface, LAN, or even device. Or you could break your +network into smaller chunks like /56 or /60. + +The format of these addresses: + +- `2001:470:xxxx::/48`: The whole subnet. xxxx should come from Tunnelbroker. +- `2001:470:xxxx:1::/64`: A subnet suitable for a LAN +- `2001:470:xxxx:2::/64`: Another subnet +- `2001:470:xxxx:ffff:/64`: The last usable /64 subnet. + +In the above examples, 1,2,ffff are all chosen by you. You can use 1-ffff +(1-65535). + +So, when your LAN is eth1, your DMZ is eth2, your cameras live on eth3, etc: + +.. code-block:: none + + set interfaces ethernet eth1 address '2001:470:xxxx:1::1/64' + set service router-advert interface eth1 name-server '2001:4860:4860::8888' + set service router-advert interface eth1 name-server '2001:4860:4860::8844' + set service router-advert interface eth1 prefix 2001:470:xxxx:1::/64 + + set interfaces ethernet eth2 address '2001:470:xxxx:2::1/64' + set service router-advert interface eth2 name-server '2001:4860:4860::8888' + set service router-advert interface eth2 name-server '2001:4860:4860::8844' + set service router-advert interface eth2 prefix 2001:470:xxxx:2::/64 + + set interfaces ethernet eth3 address '2001:470:xxxx:3::1/64' + set service router-advert interface eth3 name-server '2001:4860:4860::8888' + set service router-advert interface eth3 name-server '2001:4860:4860::8844' + set service router-advert interface eth3 prefix 2001:470:xxxx:3::/64 + +Please note, 'autonomous-flag' and 'on-link-flag' are enabled by default, 'valid-lifetime' and 'preferred-lifetime' are set to default values of 30 days and 4 hours respectively. + +Firewall +======== + +Finally, don't forget the :ref:`firewall`. The usage is identical, except for +instead of `set firewall name NAME`, you would use `set firewall ipv6-name +NAME`. + +Similarly, to attach the firewall, you would use `set interfaces ethernet eth0 +firewall in ipv6-name` or `set zone-policy zone LOCAL from WAN firewall +ipv6-name`. diff --git a/docs/configexamples/wan-load-balancing.rst b/docs/configexamples/wan-load-balancing.rst new file mode 100644 index 00000000..7093defe --- /dev/null +++ b/docs/configexamples/wan-load-balancing.rst @@ -0,0 +1,170 @@ +.. _wan-load-balancing: + +WAN Load Balancer examples +========================== + + +Example 1: Distributing load evenly +----------------------------------- + +The setup used in this example is shown in the following diagram: + +.. image:: /_static/images/Wan_load_balancing1.png + :width: 80% + :align: center + :alt: Network Topology Diagram + + +Overview +^^^^^^^^ + * All traffic coming in trough eth2 is balanced between eth0 and eth1 + on the router. + * Pings will be sent to four targets for health testing (33.44.55.66, + 44.55.66.77, 55.66.77.88 and 66.77.88.99). + * All outgoing packets are assigned the source address of the assigned + interface (SNAT). + * eth0 is set to be removed from the load balancer's interface pool + after 5 ping failures, eth1 will be removed after 4 ping failures. + +Create static routes to ping targets +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Create static routes through the two ISPs towards the ping targets and +commit the changes: + +.. code-block:: none + + set protocols static route 33.44.55.66/32 next-hop 11.22.33.1 + set protocols static route 44.55.66.77/32 next-hop 11.22.33.1 + set protocols static route 55.66.77.88/32 next-hop 22.33.44.1 + set protocols static route 66.77.88.99/32 next-hop 22.33.44.1 + +Configure the load balancer +^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Configure the WAN load balancer with the parameters described above: + +.. code-block:: none + + set load-balancing wan interface-health eth0 failure-count 5 + set load-balancing wan interface-health eth0 nexthop 11.22.33.1 + set load-balancing wan interface-health eth0 test 10 type ping + set load-balancing wan interface-health eth0 test 10 target 33.44.55.66 + set load-balancing wan interface-health eth0 test 20 type ping + set load-balancing wan interface-health eth0 test 20 target 44.55.66.77 + set load-balancing wan interface-health eth1 failure-count 4 + set load-balancing wan interface-health eth1 nexthop 22.33.44.1 + set load-balancing wan interface-health eth1 test 10 type ping + set load-balancing wan interface-health eth1 test 10 target 55.66.77.88 + set load-balancing wan interface-health eth1 test 20 type ping + set load-balancing wan interface-health eth1 test 20 target 66.77.88.99 + set load-balancing wan rule 10 inbound-interface eth2 + set load-balancing wan rule 10 interface eth0 + set load-balancing wan rule 10 interface eth1 + +Example 2: Failover based on interface weights +---------------------------------------------- + +This examples uses the failover mode. + +Overview +^^^^^^^^ +In this example eth0 is the primary interface and eth1 is the secondary +interface to provide simple failover functionality. If eth0 fails, eth1 +takes over. + +Create interface weight based configuration +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +The configuration steps are the same as in the previous example, except +rule 10 so we keep the configuration, remove rule 10 and add a new rule +for the failover mode: + +.. code-block:: none + + delete load-balancing wan rule 10 + set load-balancing wan rule 10 failover + set load-balancing wan rule 10 inbound-interface eth2 + set load-balancing wan rule 10 interface eth0 weight 10 + set load-balancing wan rule 10 interface eth1 weight 1 + +Example 3: Failover based on rule order +--------------------------------------- + +The previous example used the failover command to send traffic thorugh +eth1 if eth0 fails. In this example failover functionality is provided +by rule order. + +Overview +^^^^^^^^ +Two rules will be created, the first rule directs traffic coming in +from eth2 to eth0 and the second rule directs the traffic to eth1. If +eth0 fails the first rule is bypassed and the second rule matches, +directing traffic to eth1. + +Create rule order based configuration +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +We keep the configurtation from the previous example, delete rule 10 +and create the two new rules as described: + +.. code-block:: none + + delete load-balancing wan rule 10 + set load-balancing wan rule 10 inbound-interface eth2 + set load-balancing wan rule 10 interface eth0 + set load-balancing wan rule 20 inbound-interface eth2 + set load-balancing wan rule 20 interface eth1 + +Example 4: Failover based on rule order - priority traffic +---------------------------------------------------------- + +A rule order for prioritising traffic is useful in scenarios where the +secondary link has a lower speed and should only carry high priority +traffic. It is assumed for this example that eth1 is connected to a +slower connection than eth0 and should prioritise VoIP traffic. + +Overview +^^^^^^^^ +A rule order for prioritising traffic is useful in scenarios where the +secondary link has a lower speed and should only carry high priority +traffic. It is assumed for this example that eth1 is connected to a +slower connection than eth0 and should prioritise VoIP traffic. + +Create rule order based configuration with low speed secondary link +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +We keep the configuration from the previous example, delete rule 20 and +create a new rule as described: + +.. code-block:: none + + delete load-balancing wan rule 20 + set load-balancing wan rule 20 inbound-interface eth2 + set load-balancing wan rule 20 interface eth1 + set load-balancing wan rule 20 destination port sip + set load-balancing wan rule 20 protocol tcp + set protocols static route 0.0.0.0/0 next-hop 11.22.33.1 + +Example 5: Exclude traffic from load balancing +---------------------------------------------- + +In this example two LAN interfaces exist in different subnets instead +of one like in the previous examples: + +.. image:: /_static/images/Wan_load_balancing_exclude1.png + :width: 80% + :align: center + :alt: Network Topology Diagram + +Adding a rule for the second interface +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Based on the previous example, another rule for traffic from the second +interface eth3 can be added to the load balancer. However, traffic meant +to flow between the LAN subnets will be sent to eth0 and eth1 as well. +To prevent this, another rule is required. This rule excludes traffic +between the local subnets from the load balancer. It also excludes +locally-sources packets (required for web caching with load balancing). +eth+ is used as an alias that refers to all ethernet interfaces: + +.. code-block:: none + + set load-balancing wan rule 5 exclude + set load-balancing wan rule 5 inbound-interface eth+ + set load-balancing wan rule 5 destination address 10.0.0.0/8 diff --git a/docs/configexamples/zone-policy.rst b/docs/configexamples/zone-policy.rst new file mode 100644 index 00000000..bfe77c2e --- /dev/null +++ b/docs/configexamples/zone-policy.rst @@ -0,0 +1,415 @@ +.. _examples-zone-policy: + +Zone-Policy example +------------------- + +Native IPv4 and IPv6 +^^^^^^^^^^^^^^^^^^^^ + +We have three networks. + +.. code-block:: none + + WAN - 172.16.10.0/24, 2001:0DB8:0:9999::0/64 + LAN - 192.168.100.0/24, 2001:0DB8:0:AAAA::0/64 + DMZ - 192.168.200.0/24, 2001:0DB8:0:BBBB::0/64 + + +**This specific example is for a router on a stick, but is very easily +adapted for however many NICs you have**: + + +* Internet - 192.168.200.100 - TCP/80 +* Internet - 192.168.200.100 - TCP/443 +* Internet - 192.168.200.100 - TCP/25 +* Internet - 192.168.200.100 - TCP/53 +* VyOS actis as DHCP, DNS forwarder, NAT, router and firewall. +* 192.168.200.200/2001:0DB8:0:BBBB::200 is an internal/external DNS, web + and mail (SMTP/IMAP) server. +* 192.168.100.10/2001:0DB8:0:AAAA::10 is the administrator's console. It + can SSH to VyOS. +* LAN and DMZ hosts have basic outbound access: Web, FTP, SSH. +* LAN can access DMZ resources. +* DMZ cannot access LAN resources. +* Inbound WAN connect to DMZ host. + +.. image:: /_static/images/zone-policy-diagram.png + :width: 80% + :align: center + :alt: Network Topology Diagram + +The VyOS interface is assigned the .1/:1 address of their respective +networks. WAN is on VLAN 10, LAN on VLAN 20, and DMZ on VLAN 30. + +It will look something like this: + +.. code-block:: none + + interfaces { + ethernet eth0 { + duplex auto + hw-id 00:53:ed:6e:2a:92 + smp_affinity auto + speed auto + vif 10 { + address 172.16.10.1/24 + address 2001:db8:0:9999::1/64 + } + vif 20 { + address 192.168.100.1/24 + address 2001:db8:0:AAAA::1/64 + } + vif 30 { + address 192.168.200.1/24 + address 2001:db8:0:BBBB::1/64 + } + } + loopback lo { + } + } + + +Zones Basics +^^^^^^^^^^^^ + +Each interface is assigned to a zone. The interface can be physical or +virtual such as tunnels (VPN, PPTP, GRE, etc) and are treated exactly +the same. + +Traffic flows from zone A to zone B. That flow is what I refer to as a +zone-pair-direction. eg. A->B and B->A are two zone-pair-destinations. + +Ruleset are created per zone-pair-direction. + +I name rule sets to indicate which zone-pair-direction they represent. +eg. ZoneA-ZoneB or ZoneB-ZoneA. LAN-DMZ, DMZ-LAN. + +In VyOS, you have to have unique Ruleset names. In the event of overlap, +I add a "-6" to the end of v6 rulesets. eg. LAN-DMZ, LAN-DMZ-6. This +allows for each auto-completion and uniqueness. + +In this example we have 4 zones. LAN, WAN, DMZ, Local. The local zone is +the firewall itself. + +If your computer is on the LAN and you need to SSH into your VyOS box, +you would need a rule to allow it in the LAN-Local ruleset. If you want +to access a webpage from your VyOS box, you need a rule to allow it in +the Local-LAN ruleset. + +In rules, it is good to keep them named consistently. As the number of +rules you have grows, the more consistency you have, the easier your +life will be. + +.. code-block:: none + + Rule 1 - State Established, Related + Rule 2 - State Invalid + Rule 100 - ICMP + Rule 200 - Web + Rule 300 - FTP + Rule 400 - NTP + Rule 500 - SMTP + Rule 600 - DNS + Rule 700 - DHCP + Rule 800 - SSH + Rule 900 - IMAPS + +The first two rules are to deal with the idiosyncrasies of VyOS and +iptables. + +Zones and Rulesets both have a default action statement. When using +Zone-Policies, the default action is set by the zone-policy statement +and is represented by rule 10000. + +It is good practice to log both accepted and denied traffic. It can save +you significant headaches when trying to troubleshoot a connectivity +issue. + +To add logging to the default rule, do: + +.. code-block:: none + + set firewall name <ruleSet> enable-default-log + + +By default, iptables does not allow traffic for established session to +return, so you must explicitly allow this. I do this by adding two rules +to every ruleset. 1 allows established and related state packets through +and rule 2 drops and logs invalid state packets. We place the +established/related rule at the top because the vast majority of traffic +on a network is established and the invalid rule to prevent invalid +state packets from mistakenly being matched against other rules. Having +the most matched rule listed first reduces CPU load in high volume +environments. Note: I have filed a bug to have this added as a default +action as well. + +''It is important to note, that you do not want to add logging to the +established state rule as you will be logging both the inbound and +outbound packets for each session instead of just the initiation of the +session. Your logs will be massive in a very short period of time.'' + +In VyOS you must have the interfaces created before you can apply it to +the zone and the rulesets must be created prior to applying it to a +zone-policy. + +I create/configure the interfaces first. Build out the rulesets for each +zone-pair-direction which includes at least the three state rules. Then +I setup the zone-policies. + +Zones do not allow for a default action of accept; either drop or +reject. It is important to remember this because if you apply an +interface to a zone and commit, any active connections will be dropped. +Specifically, if you are SSH’d into VyOS and add local or the interface +you are connecting through to a zone and do not have rulesets in place +to allow SSH and established sessions, you will not be able to connect. + +The following are the rules that were created for this example (may not +be complete), both in IPv4 and IPv6. If there is no IP specified, then +the source/destination address is not explicit. + +.. code-block:: none + + WAN – DMZ:192.168.200.200 – tcp/80 + WAN – DMZ:192.168.200.200 – tcp/443 + WAN – DMZ:192.168.200.200 – tcp/25 + WAN – DMZ:192.168.200.200 – tcp/53 + WAN – DMZ:2001:0DB8:0:BBBB::200 – tcp/80 + WAN – DMZ:2001:0DB8:0:BBBB::200 – tcp/443 + WAN – DMZ:2001:0DB8:0:BBBB::200 – tcp/25 + WAN – DMZ:2001:0DB8:0:BBBB::200 – tcp/53 + + DMZ - Local - tcp/53 + DMZ - Local - tcp/123 + DMZ - Local - tcp/67,68 + + LAN - Local - tcp/53 + LAN - Local - tcp/123 + LAN - Local - tcp/67,68 + LAN:192.168.100.10 - Local - tcp/22 + LAN:2001:0DB8:0:AAAA::10 - Local - tcp/22 + + LAN - WAN - tcp/80 + LAN - WAN - tcp/443 + LAN - WAN - tcp/22 + LAN - WAN - tcp/20,21 + + DMZ - WAN - tcp/80 + DMZ - WAN - tcp/443 + DMZ - WAN - tcp/22 + DMZ - WAN - tcp/20,21 + DMZ - WAN - tcp/53 + DMZ - WAN - udp/53 + + Local - WAN - tcp/80 + Local - WAN - tcp/443 + Local - WAN - tcp/20,21 + + Local - DMZ - tcp/25 + Local - DMZ - tcp/67,68 + Local - DMZ - tcp/53 + Local - DMZ - udp/53 + + Local - LAN - tcp/67,68 + + LAN - DMZ - tcp/80 + LAN - DMZ - tcp/443 + LAN - DMZ - tcp/993 + LAN:2001:0DB8:0:AAAA::10 - DMZ:2001:0DB8:0:BBBB::200 - tcp/22 + LAN:192.168.100.10 - DMZ:192.168.200.200 - tcp/22 + +Since we have 4 zones, we need to setup the following rulesets. + +.. code-block:: none + + Lan-wan + Lan-local + Lan-dmz + Wan-lan + Wan-local + Wan-dmz + Local-lan + Local-wan + Local-dmz + Dmz-lan + Dmz-wan + Dmz-local + +Even if the two zones will never communicate, it is a good idea to +create the zone-pair-direction rulesets and set enable-default-log. This +will allow you to log attempts to access the networks. Without it, you +will never see the connection attempts. + +This is an example of the three base rules. + +.. code-block:: none + + name wan-lan { + default-action drop + enable-default-log + rule 1 { + action accept + state { + established enable + related enable + } + } + rule 2 { + action drop + log enable + state { + invalid enable + } + } + } + + +Here is an example of an IPv6 DMZ-WAN ruleset. + +.. code-block:: none + + ipv6-name dmz-wan-6 { + default-action drop + enable-default-log + rule 1 { + action accept + state { + established enable + related enable + } + } + rule 2 { + action drop + log enable + state { + invalid enable + } + rule 100 { + action accept + log enable + protocol ipv6-icmp + } + rule 200 { + action accept + destination { + port 80,443 + } + log enable + protocol tcp + } + rule 300 { + action accept + destination { + port 20,21 + } + log enable + protocol tcp + } + rule 500 { + action accept + destination { + port 25 + } + log enable + protocol tcp + source { + address 2001:db8:0:BBBB::200 + } + } + rule 600 { + action accept + destination { + port 53 + } + log enable + protocol tcp_udp + source { + address 2001:db8:0:BBBB::200 + } + } + rule 800 { + action accept + destination { + port 22 + } + log enable + protocol tcp + } + } + +Once you have all of your rulesets built, then you need to create your +zone-policy. + +Start by setting the interface and default action for each zone. + +.. code-block:: none + + set zone-policy zone dmz default-action drop + set zone-policy zone dmz interface eth0.30 + +In this case, we are setting the v6 ruleset that represents traffic +sourced from the LAN, destined for the DMZ. Because the zone-policy +firewall syntax is a little awkward, I keep it straight by thinking of +it backwards. + +.. code-block:: none + + set zone-policy zone dmz from lan firewall ipv6-name lan-dmz-6 + +DMZ-LAN policy is LAN-DMZ. You can get a rhythm to it when you build out +a bunch at one time. + +In the end, you will end up with something like this config. I took out +everything but the Firewall, Interfaces, and zone-policy sections. It is +long enough as is. + + +IPv6 Tunnel +^^^^^^^^^^^ + +If you are using a IPv6 tunnel from HE.net or someone else, the basis is +the same except you have two WAN interface. One for v4 and one for v6. + +You would have 5 zones instead of just 4 and you would configure your v6 +ruleset between your tunnel interface and your LAN/DMZ zones instead of +to the WAN. + +LAN, WAN, DMZ, local and TUN (tunnel) + +v6 pairs would be: + +.. code-block:: none + + lan-tun + lan-local + lan-dmz + tun-lan + tun-local + tun-dmz + local-lan + local-tun + local-dmz + dmz-lan + dmz-tun + dmz-local + +Notice, none go to WAN since WAN wouldn't have a v6 address on it. + +You would have to add a couple of rules on your wan-local ruleset to +allow protocol 41 in. + +Something like: + +.. code-block:: none + + rule 400 { + action accept + destination { + address 172.16.10.1 + } + log enable + protocol 41 + source { + address ip.of.tunnel.broker + } + } + |