@BarryVereijssen said in Switching from KPN PPPoE to IPoE: @wickeren I have the same issue (also KPN zakelijk) did you find a solid solution? I have an all Unifi setup (USG Pro as router) and want implement this IPoE too. This forum is about Pfsense, not about Ubiquiti. Doesn’t have one too so can’t help...

States should not matter. Your pfsense GUI will answer on any of its IP addresses WAN or LAN on whatever port you have assigned the GUI as long as there is a firewall rule allowing. If you have an incoming firewall rule on your WANs with "WAN Address" as Destination then it will work. You simply have to enter it's WAN address on your REMOTE client. If you are hitting your WAN address from inside your LAN then of coarse it will still work even if WAN 1 is down as long as the interface still is latched onto its address (DHCP) or anytime if it is static.

Further searches reveal that most European cellular carriers are using the CGNAT trick for the mass market, including my carrier. The down side seems to be that VPNs etc won't work. On the up side it transpires that my carrier and some others offer fixed IP cellular SIMs but they are expensive with limited data allocation. It would be strictly a backup plan and more pricey than a whole additional broadband wired wan. The reason to use it would be that mostly only city folk in the UK can get choice of dual independent WAN feeds. Thank you for your quick recognition of the problem.

I recently had the same issue and I was able to fix it. I know it is probably to late for you but I'll provide the solution . Maybe someone else need it too. The issue with 'can't handle afxxx' can be fixed by creating a firewall rule on the internal interface (LAN) and allow traffic thru the proper gateway. The steps needed to fix it are: Go to Firewall menu -> Rules then select LAN interface (instead of LAN you should use the name of your local network interface) Click add to top button [image: 1567715838036-bead74ba-2621-4330-8792-ce50af75de2e-image.png] and fill the filelds properly. How to fill the fields properly: Action: Pass Interface: LAN Protocol: Any Source: 'Single Host or Alias' or 'Network' and type the IP or Alias or Network you want to use with the second WAN Destination: Any Click Display Advanced button [image: 1567716350267-3f255487-3106-4e32-a5ac-0579093191dd-image.png] Go to Gateway and select from the list the default gateway for your second WAN Click Save [image: 1567716670538-ff019bfc-24fe-4449-9237-f9ef75e9baff-image.png] Click Apply Chnges [image: 1567716634040-cbe333f9-fa85-4b19-861d-cb9fd344ea77-image.png]

Read this entire thread: https://forum.netgate.com/topic/146163/failover-internet-just-for-two-clients-on-the-network

@kklouzal said in Multi-LAN Routing Without Bridge Interface: Proposed Configuration: Remove the bridge interface. Set the LAN facing LAGG to 192.168.1.1/24 IPv4 Configuration Type along with Track Interface WAN IPv6 Configuration Type. Keep the 4 LAN facing OPT interfaces as NONE for their IPv4/IPv6 Configuration Type. Configure PfSense to now filter packets on member interfaces and not on the bridge interface. Add firewall rules to allow traffic to pass between all 5 LAN facing interfaces. If you remove the bridge configuration and keep the 4 other OPT interfaces on "NONE" as their configuration type, they will simply do nothing as neither L2 nor L3 has anything to do for them. You can't configure pfSense to send packets to an interface. That's where you either do bridging (meh) or routing (and per definition a L3 configuration with IP addresses). Specifically will they ensure clients connected to the OPT interfaces can obtain an IP address from the DHCP server running on the LAGG interface? To do that, use the DHCP Relay and send the requests to the LAN facing LAGG If the answer to that is no then I can set all 5 Configuration Types to Track Interface WAN for IPv6 and IPv4 to Static giving each interface an address on a unique subnet (192.168.1.1/24, 192.168.2.1/24, 192.168.3.1/24, 192.168.4.1/24, 192.168.5.1/24). You have to do a part of that (IP4/6 configuration). As said, you can also run DHCP relay to hand out IPs for devices on opt1-4 but they have to be on their own subnet to have a clean routing setup. But if you don't have to do that (because that central DHCP is needed for Client DynDNS or something), then running DHCP on pfSense is perfectly good, too. Greets

Add MX64 as Gateway, add static route for remote network to said gateway, done :)

After i try to verify one by one. Now i saw a problem and solve it . I assign a wrong get way on router. Really happy and Thank you for all your help.

Why did you start another thread on this? If your routing is correct, then yes firewalls could be an issue. Also policy routing could be problem.. If your using say a vpn on pfsense, and sending traffic out some vpn interface before you allow it to go to the mik to get to the 172.16 network. You would have to put a rule above your policy route to be able to allow 192.168 to ping 172.16

I'll try that, thanks.

Use the HAProxy package in pfsense itself. Here's some walkthroughs on setup: https://blog.devita.co/pfsense-to-proxy-traffic-for-websites-using-pfsense/ https://www.thawes.com/2018/01/configuring-pfsense-haproxy-http-https/ http://nathandarnell.com/haproxy-in-pfsense-as-a-reverse-proxy Here's the documentation: https://docs.netgate.com/pfsense/en/latest/packages/haproxy-package.html Here's the cache/proxy forum topic here with lots of posts: https://forum.netgate.com/category/52/cache-proxy Jeff

Hi Thanks yeah I had done all of that and it wasn't working.. However in the Open VPN Server advanced configuration I did add a push route for 10.190.36.0 255.255.255.0 and now I am able to communicate with resources on the Worthing LAN. So I am guessing this was the missing link...

yup there is that option but obviusly i can't try it

@sho1sho1sho1 Please show Diagnostics / Routes

Just remember doing this can be a bit harder on the resources of the box. Especially if you have allot of LAN to LAN traffic..

Add another MX record to point to your isp b WAN address. That way mail should be able to reach your mail server no matter which gateway is up.

It didn't help. Any traffic initiated from external sources via that tunnel ends up being responded via WAN interface. Any ideas?

You can't hairpin NAT like that with FreeBSD/pf. They won't be able to reach each other through the WAN address. With manual port forward rules, you can enable NAT reflection which adds more rules behind the scenes to cover that scenario. That is not possible with UPnP.