Your issue has absolutely no relation to the OP's issue.

Hi.. thanks for your answer, yes i think i'd rather add another interface on the shaper box, so i don't need to add more tuning to pfsense.. SO basically i should just use e.g : Add interface 192.168.2.1 for shaper , and replace 192.168.1.5 with 192.168.2.2 on the linux router box, Am I correct ?

thank you for replying phil you really help a lot thank you

Solved with an OpenVPN tunnel :) I had hard time to make it work but seems very responsive and stable.

Quick update : In my setup my pfSense server has IP 192.168.0.42/24 but a virtual IP (menu Firewall: Virtual IP Address) of type "IP alias" (on Interface "LAN") makes him available via 192.168.0.254/24 (I'm considering this IP as my gateway IP and then I'm free to use whatever server I want as long as it responds to 192.168.0.254/24. But Unbound package (v1.4.22), when asked to listen on "Network interface" LAN and loopback seems ignore this virtual IP. I can successfully contact Unbound on 192.168.0.42: nslookup www.pfsense.org 192.168.0.42 Server:        192.168.0.42 Address:        192.168.0.42#53 Non-authoritative answer: Name:  www.pfsense.org Address: 208.123.73.69 But it fails on 192.168.0.254: nslookup www.pfsense.org 192.168.0.254 ;; connection timed out; no servers could be reached GUI and netstat confirms it: Menu Services: Unbound DNS Forwarder: Status: Unbound configuration: [...] # Interface IP(s) to bind to interface: 192.168.0.42 interface: 127.0.0.1 interface: ::1 [...] [2.1.2-RELEASE][admin@router.example.com]/(36): netstat -n | grep 53 udp6      0      0 ::1.53                *.* udp4      0      0 127.0.0.1.53          *.* udp4      0      0 192.168.0.42.53        *.* c8e86ec8 stream      0      0 c8e3f53c        0        0        0 /var/run/check_reload_status Is there a way to add the "interface: 192.168.0.254" Unbound directive (GUI or CLI)? Tried to add it in "Services: Unbound DNS Forwarder: Advanced Settings: Custom Options" but Unbound then fails to start… If this is not supported by this package nor the pfSense UI could I set up some "iptables" redirection?

That fixes the problem you were having between LAN1 and LAN2. But now all the LAN1 internet traffic will just go out the default gateway. If you were wanting failover or outbound load balancing then you will have to be a bit more fancy with the rules - 1 to pass local traffic, and the next to send the rest to a gateway group.

Right so I have the bridge working now by adding the interface as suggested. The high CPU load and dropping packets hasn't re-materialised. I've now added an any any rule to all three interfaces just to get it working. Now I need to understand how so stop it working in a controlled way if you know what I mean. I'm not too sure if I just use the "filter on the bridge interface" setting what the rules need to look like. If I try to keep the "filtering on incoming and outgoing member interface" I get in all sorts of trouble and it all grinds to a hault. Thank god for the restore last config setting via console what a fantastic option. I'm sure I'll figure it out, shouldn't really attempt this stuff when you get home from a hard days work. Always makes it take twice as long. Cheers. [image: Untitled6.png] [image: Untitled7.png] [image: Untitled8.png] [image: Untitled9.png] [image: Untitled10.png] [image: Untitled11.png]

Maybe this sort of thing, lets call the devices: a) "Front pfSense", which has OFFSITELAN as a VLAN, and WAN and WAN2. b) "Back pfSense" which has its WAN on Front pfSense LAN. And Back pfSense LAN has some ordinary local users also. Front pfSense a) add a gateway to Back pfSense WAN IP - "BackGW". Probably no need for a route. b) On OFFSITELAN add a rule, pass source OFFSITELANnet, destination any, gateway "BackGW" Back pfSense a) On WAN add pass rule to allow source OFFSITELAN subnet. b) Firewall->NAT Outbound, go to manual and add NAT rule on WAN for source OFFSITELAN, destination any, NAT to WAN address - this will ensure that packets from OFFSITELAN get their source address changed to the Back pfSense WAN IP, and so returning packets will have to be routed by Front pfSense to Back pfSense, and unNATed to deliver again to Front pfSense, which will deliver to the OFFSITELAN client. That should all work without any Squid. Then add Squid to the equation and see what happens!

Just because 42 is the meaning of life, the universe and everything, you still can't use it as the IP address of every device  ;) Glad you found the issue. I couldn't resist looking up 42.42.42.42 - it is allocated to somewhere in South Korea. Shame they don't have a Hitchhikers Guide site running there.

Hi zerokool, not sure, what you want to accomplish. Do you want one public hostname for the complete trunk of your WANs? The only way I can think of to achieve that is to install pfSense on a hosted webserver with a big uplink as a "RDP gateway". Then configure VPNs on each WAN link of your local pfS box to that server. Load Balance the VPNs. Then connect your RDP clients to the webserver. That means a lot of configuration and security thoughts and some $ for the hosted server and bandwidth. What you can do without additional costs is to build gateway groups (e.g. 2 gateways per group for redundancy) and assign the DynDNS name to a group. But AFAIK in that scenario only one gateway is used, so that's not loadbalancing. You could only do some manual "loadbalancing" setting your clients up to use different DynDNS hosts and therefore gateway groups. Hope this could lead you to further steps. Good luck! Harry

Ok so i added a new firewall rule to use the 172.16.2.2 gateway, .. first and then the default gateway second, however it still keeps on using that verry same IP the IP doesn't change.

Ignore my post. I got it done without issue. Thanks. Tom.

Shame on me, THAT was the issue  :-X the gateway on the destination IP was yet the Draytek one, thus the ICMP packet was being lost during the path. You just made my day! Many thanks Phil!!  :D

the change of acl firewall priority doesn´t solve the problem. I do a update of version 2.1.1 (before 2.1) but this do not solve the problem, too. Anybody have a idea?

I think "Use sticky connections" is for load-balancing incoming traffic forwarded in from the internet to web servers. I just posted this - https://forum.pfsense.org/index.php?topic=74931.msg408997#msg408997 - it is not quite what you are describing. I had a feeling that there was somewhere in the rule advanced options that you could tell stuff from 1 client to stick to the WAN that is first used, but I can't spot it now. Maybe I was dreaming of it?