I did a lot of searching on this topic and really I found nothing that gave the full setup and explanation that made sense to me, so I ended up going back to an older version(1.231) of Monowall to clear up the issue. I then updated until Hamachi stopped working. Looking at the version change log I found that there was a change that made the firewall remap the ports for UDP connection. Where this is slightly more secure, it is also not compatible with Hamachi. False Hope(Skip this if you don't care to know what not to do.) Before I found the correct solution,I first had a false positive correction where I setup each internal Hamachi instance to have its own port to connect with. This is done by setting up the UDP IP and port for the Hamachi instance in Hamachi advanced settings. Then Adding a port forward for each one in the firewall. This seems to work at first but when you have PCs that disconnect and reconnect over time they will all go to Relay Tunnel. This is because at first the ports that are assigned are used but at some point they get remapped. This can be confusing because if you restart the internal Hamachi instance, it will clear up for all connected clients. This is not a solution. Since you will find your self running around every day resetting Hamachi instances or setting up restart times for the Hamachi service. To make Hamachi work on either Monowall or Pf-sense, you have to create an Outbound NAT rule for your Lan network Subnet that has the disable port mapping checked. Then turn enable Advanced outbound Nat. When you don't have (AON ) turned on there is a rule just like this created for you but without the port mapping turned off. Basically your rule should look something resembling this(see below) if you have a Lan setup like with 192.168.0.x / 24 (Subnet:255.255.255.0) . Create a NAT Outbound mapping entry that has these settings. (see attached image for monowall screen shot.) Interface:wan Source: 192.168.0.0 / 24 Destination: any Target: blank Portmap: checked Description: [what ever you like] Don't forget to turn on AON (check box ) If this entry is correct you should not see any changes to your FW operation. The only real difference you should see is that Hamachi and other UDP using traffic should start to work as expected. Hope this helps someone, I know it would have helped me save several days of experimenting. [image: monowall_AON-Hamachi.png] [image: monowall_AON-Hamachi.png_thumb]

Un-ticking 'Use sticky connections' in System -> Advanced -> Load Balancing did the trick!

You don't really need multiple failover pools. A single wan1 fails to wan2 fails to wan3 should be enough. (Of course the WANs should be in the order in which you want them to failover).

Yes this should be possible. With 2.0 you will have the possibility to terminate all the PPPoE links directly on the pfSense. However if these links are from the same provider you might run into the problem, that two links are not allowed to have the same gateway.

;D

Ok, we'll do that then. Problem seems to have solved itself somewhat, it appears we're getting a /28 from the start as those 2 free addresses weren't enough anyway. Thanks for your advice :)

The overlapping VPN endpoints is the key – we won't be able to control what network ranges they might happen to use on their side, so I guess I'll just need to get pfSense installed and test things out..

Yes. With 2.0 you will have the option to terminate all the PPPoE connections on the pfSense. However the limitation that no two WANs can have the same gateway still applies.

@Jahntassa: I had to do this with Manual NAT and a rule in the Outbound tab. I think if you leave it on Automatic NAT you'd have to do a Static Route of some sort. I could be wrong though. Problem solved, I did this Firewall -> NAT -> Outbound -> mark Automatic outbound NAT rule generation Then go to Firewall -> Rules -> Lan and create a rule like this: proto: tcp/udp source: 192.168.1.13 (Local IP to the machine) port: * destination: * port: * gateway: WAN5OPT4 (Interface)

@jimp: What version are you using? I don't think sticky worked properly in 1.2.x, but it should be fixed in 2.0. 1.2.3  I'm not using 2.0 because of its beta status.

Thank you very much!!

SOLVED !!! Everything is ok. The port 5060 was blocked from the teleconference device. So it works perfectly now with OPT bridged to WAN and assigning the static ip to the teleconference. Also PASS rule to OPT and Wan is needed. Thanks.

I know … my loss is not complete though! I still want to do it... how should I go Regards

;D that would be great, downloading and burning now, lets see :) [update:] and its broken. updated to latest beta, and even after a 'factory reset', I can't get connection with either the pppoe internet, or the 172 'wan' anyway, I'm tired, I'll try again tomorrow. :)

Sorry to reply so late. Both WAN1 and WAN2 are static IP. WAN1 IP = 10.1.1.2 Gateway 10.1.1.1 (Modem IP) WAN2 IP = 10.1.2.2 Gateway 10.1.2.1 (Modem IP)

Two lines with the same gateway will not work. Though if your ISP supports MLPPP, you could bond them that way and then you wouldn't need load balancing. Failing that, you'd need some other little cheap NAT device to make the duplicate WANs appear as different subnets.

Your description what you want to do is pretty confusing…. From what i can guess you need an outbound rule (Firewall --> NAT --> outbound) on your WAN2 with as source IP your VIP.

Now I found the problem why the NAT is not working and I think it is a Bug in the pfSense 1.2.3. It looks like that the "NAT Port Forward" have got problems with "Aliases" type "PORTS" I create a Alias with 2 Ports (80, 443) type "Ports(s). I use this in my Alias in my Port Forward rule. After I try to get on the external IP over a internal Network, it doesn't work. Now I split the Port Forward rule into to rules without a alias and use for the one rule the port 80 and for the other one 443. And now BINGO, it works, I can access a Webpage from the internal network to the external address what is a port forward to our internal network. Now I test this on a another pfSense installation that we have in a another location and I can reproduce the problem on that one too. So it looks like the version 1.2.3 have the bug with PORT ALIASES. Hope this can help other users now. Best, PD