@knobby unfortunately, I moved on to fixed wireless internet that gives me better internet speed and stability. Good luck with your findings.

Just to close the loop on this - I re-enabled pf with any/any inbound and outbound with NAT disabled and have not found any resulting issues. From a performance perspective, I saw about a 50% performance hit in throughput. Luckily, I'm running this instance as a VM so by adding a second core to this instance, I'm back to near wire speed with pf running. ESXi 7 on AMD Ryzen 5 3600 CPU if anyone is interested. Thanks for the replies on this.

@Stewart said in Failing over too early: I'd assume that setting would be for if we select the High Latency option. There is no such option. It is part of the gateway monitoring (dpinger) mechanism for determining the gateway status. I agree with @serbus . There is more than one factor which will mark a gateway as down. Packet loss is only one factor, the other is latency. If packets are taking too long to get a response, this can also cause your gateway to be marked as down. To confirm what the actual problem is, go to Status/System Logs/System/Gateways. What does the log there say when your gateway is marked down? You can post a screenshot and don't forget to blank out your WAN IP.

You appear to be trying to configure an unsupported role. The /64 for NPt must be routed to pfSense. If the upstream expects it to respond to NDP on the WAN segment, that cannot work. pfSense does not support the concept of proxying NDP requests. If you have a handful of static addresses on the inside, you could setup IP alias VIPs on the WAN for those, but automatic assignment wouldn't be possible.

Your ubuntu server will get in quite a pinch with that routing table: 172.24.0.0 0.0.0.0 255.255.252.0 U 0 0 0 eth1 172.24.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 Those are clearly overlapping and even configured to separate interfaces. That's no nice way to route. If you ever have some 172.24.1.x addresses on eth1 those won't work. That's a thing we call "accident/disaster in the making" at work ;)

Hi, I found a tutorial on YouTube which shows that the IPSec tunnel in created by wan to wan instead of GRE to GRE Doesn't this negate the purpose on masking the IPSec with GRE? https://youtu.be/YPYFcya3Qls Any hints? Rgd

@info12 Hmm, you're doing several dangerous things right now. RDP already obsolete: https://smallbiztrends.com/2018/10/rdp-hacking.html The new pfSense version is 2.4.5 -p1 the public IP address is not usually (never) indicated The information you provided, really much more than less.

@The-Juggler said in problem routing with AWS marketplace version: r inside an aws vpc to give users remote access I take it you have set up the cloud/ vps firewall rules in the control console of aws ,and ports ? .With most instances unless the port is changed on pfsense for web access it will transfer the rules across to the wan firewall ruleset from the aws cloud firewall rules. I have set these up and you will need NAT rules on the WAN with a single interface or it wont work,and static route rules for aws instance to aws instance with aws fw rules to allow. Option 2: Be careful in doing this as rules for forwarding have to be setup and be specific in more than one area. Enable ssh forwarding on the server ( be explicit) and on the client ,setup your rules i.e in putty for which local port (127.0.0.1 port x ) then you can point your browser or application to a port on the local client (127.0.0.1 port x) it will be forwarded to the target within the ssh tunnel you have set in putty to the internal server port you have set in the ssh forwarding rule. These rules are not nat rules but ssh forwarding rules. NOTE - ssh forwarding is not setup as a default on any ssh installation including clients. HTH

Hi. There were some fixes pushed related to Dynamic DNS and gateway groups recently : https://redmine.pfsense.org/issues/9435 The fixes will come with pfSense 2.5.0. I don't know if it fixes our problem, I haven't tried it yet. Related commits : https://github.com/pfsense/pfsense/pull/4332/commits/b85557f46a4e0c82aac7e6f7471ef6231f28c351 https://github.com/pfsense/pfsense/pull/4356/commits/d6eecfdc96cf78250ddfbbc5da1a9c1ecd9a5429 You can try to manually patch the /etc/rc.dyndns.update file.

@Griffo said in Slow Inter-VLAN Routing: @tientun I have the same issue. Strangely i'm pretty confident that this did not occur on older releases (but have no proof). I have multiple vlans, and used to connect to a windows server on the "main" vlan without issue. I recently discovered that SMB became unusable. Testing with iPerf I see performance basically start OK for a very short window then completely die to zero. I'll post logs soon. What NIC do you use? I guess this problem is related to my realtek NIC.

I am a bit unsure how to do this. Is there any step by step directions please?

I messed about with it for a day and gave up and used Linux to do the routing. I set a route via interface rather than an IP and it bridges the PPPOE and ethernet connections happily. Put a transparent PFsense in the middle to look after the subnet and called it done.

Hi Again, I had missed something really obvious ... line a mis-addressed route. Had to be something as dumb as thins when you think about it. Thanks for politely ignoring me :)

Hard coding an IP into an application is BAD... Its crappy design no matter how you look at it. What happens when that IP changes.. Now the application has to be changed.. If the application used a fqdn to talk to whatever it is it needs to talk to.. All that has to happen is that fqdn points to whatever IP this services it running on.. It could change daily for that matter, etc. The only scenario where you would have to use nat reflection is when the application in use is hard coded to that specific public IP.. Which would be a crappy designed application ;) edit: Its possible the OP doesn't even have a fqdn that points to this public IP.. You can get a ddns fqdn that points to your public IP for "free".. so then just use the fqdn vs the IP, and again the need for nat reflection goes away.. If this is business use, you can get a domain for like $10 a year. I stand by my opinion - if your using IP vs a fqdn to access pretty much anything its crappy design.. edit: Here you go - the person that uses hard coded IPs in an application vs fqdn.. Prob the same person that would design something like this [image: 1593873528400-firealarm.png] ie they didn't think it through = crappy design ;)

if you need to direct the traffic to to specific GW use Policy Routing https://docs.netgate.com/pfsense/en/latest/routing/directing-traffic-with-policy-routing.html#directing-traffic-with-policy-routing

Hello. You're right, but for now that's not the problem. Packets to 192.168.2.0 don't reach 10.0.0.2, as they are sent to the mac address of 10.0.0.1. The static route does not work. The problem could be, that both gateways are on the same network (10.0.0.0)? If I deactivate the upstream for the wan interface the static route works...