Uno scenario prevede:

• Due sedi distaccate collegate tramite due firewall GNU/Linux e tunnel OpenVPN.
• Utilizzo del firewall Shorewall su enrambi i firewall.
• Una connessione OpenVPN roadwarrior che si collega ad una delle due sedi.
• Necessità da parte del roadwarrior di accedere alla LAN di entrambe le sedi.
• OpenVPN configurate con chiavi PSK sia per il tunnel A-B che per i roadwarrior. Questo significa che ogni tunnel ha la sua interfaccia PtP individuale e la topologia di rete è del tipo net30 (vedi parametro --topology di OpenVPN).

Consideriamo la Sede A come sede principale, quella alla quale si connette il roadwarrior. Il firewall di questa sede userà il tun99 per connettersi alla Sede B e l'interfaccia tun7 per accettare il roadwarrior. Sarà necessario impostare l'opzione routeback nel file /etc/shorewall/interfaces, relativamente alle interfacce tun+:

vpn   tun+   routeback

In questo modo si evita il problema sul forward, che sarebbe evidenziato con questo messaggio di log:

FORWARD REJECT IN=tun7 OUT=tun99 MAC= SRC=172.16.7.2 DST=10.1.3.52 ...

Anche per la Sede B il tunnel che collega le due sedi è identificato dall'interfaccia tun99.

Nella configurazione OpenVPN della sede B è necessario indicare quali sono gli indirizzi IP dei client OpenVPN roadwarrior che devono accedere alla LAN tramite il tun99. Quindi nella file di configurazione /etc/openvpn/tun99.conf si imposta:

...
# Routeback for OpenVPN clients coming thorough this tunnel.
# Accepted PtP addresses from 172.16.0.0 to 172.16.63.255
route 172.16.0.0 255.255.192.0 vpn_gateway
...

Con la riga di configurazione sopra, si considera rouotate tramite il tun99 tutti gli indirizzi IP da 172.16.0.0 a 172.16.63.255, pertanto i roadwarrior dovranno essere configurati di conseguenza.

Altrimenti l'indirizzo del roadwarrior verrebbe considerato marziano quando compare nel tunnel tun99, perché per le regole di routing sarebbe accettabile solo se provenisse dal default gateway:

IPv4: martian source 10.1.3.52 from 172.16.7.2, on dev tun99