<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[MutiWAN, Double NAT]]></title><description><![CDATA[<p dir="auto">I have the following scenario: 1 public IP on a pfSense WAN. From this first box, 2 radio links to a remote site, each on their own interface (LAN and OPT1) and private subnet (192.168.1.0/24 and 192.168.2.0/24). On the remote side, a pfSense box configured with MultiWAN to handle link aggregation, and more importantly link failover for the incoming radio links. A third private subnet (192.168.3.0/24) is used for devices connected to the remote network. See attachment for a diagram.</p>
<p dir="auto">This setup "works", in that connected clients on the remote side can use the internet/etc. When one radio link or the other goes down, connectivity is still available. Incoming connections from the internet, however, I cant really wrap my head around. This setup involves double NAT, so simple port forwarding doesn't work. The radios themselves are layer 2 devices, so no additional complexity there.</p>
<p dir="auto">LACP seems out, because the radio links are half-duplex.</p>
<p dir="auto">I might be able to figure out something with Quagga/OSPF, but I cant find good documentation. I also think I'd lose the link-aggregation niceness of MultiWAN if I was just dynamically updating routes based on radio link availability.</p>
<p dir="auto">Am I going about this the wrong way?<br />
<img src="/public/_imported_attachments_/1/MultiWAN.png" alt="MultiWAN.png" class=" img-fluid img-markdown" /><br />
<img src="/public/_imported_attachments_/1/MultiWAN.png_thumb" alt="MultiWAN.png_thumb" class=" img-fluid img-markdown" /></p>
]]></description><link>https://forum.netgate.com/topic/82221/mutiwan-double-nat</link><generator>RSS for Node</generator><lastBuildDate>Wed, 22 Apr 2026 08:49:21 GMT</lastBuildDate><atom:link href="https://forum.netgate.com/topic/82221.rss" rel="self" type="application/rss+xml"/><pubDate>Wed, 01 Apr 2015 23:31:23 GMT</pubDate><ttl>60</ttl></channel></rss>