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...

@DaddyGo Yesh, you are right and i am really glad that you have supported me! Wish we were in front of that(

In a moment of mental clarity, I did this: Create a GWG that fails-over on High Latency Create another GWG that Fails-over on Member Down Create firewall rule that policy routes latency sensentive devices through the Latency Fail-over GWG Create another firewal rulle that policy routes other high priority devices through the Member-Down GWG All other devices policy route through the Primary WAN only

@viragomann Hi, I have another VPN however it does not pull a default route, I have also disabled the other VPN and still, traffic is not routed over the VPN. If i untick don't pull routes then i believe it pulls a default route and everything gets routed over to Nord as apposed to only selected hosts. If i tick the disable netgate rules, i can then see traffic hitting the rule which sets the gateway and i can see states that match in the states table however if i go to a few sites to display my IP I'm still being natted to my wan ip.