I have never seen that happen. a copied rule is the same as making a new rule. It is more likely you did not adjust something that needed to be adjusted.

thank your @Derelict your awesome thank you very much .. that worked

I was talking about the rules on pfSense, of course.
As mentioned, such traffic must not be handled by floating rules. I don't know if you've set up some.

You may also do a workaround with an SNAT rule for that traffic on the Debian system to get the routing work. But maybe that's not the best solution.

@johnpoz said in Simple address forwarding:

Your going to run into all kinds of problems trying to route stuff when the stuff is on physical and doesn't use pfsense as its gateway.

If pfsense is not going to be a gateway to the internet then these networks do not even need to be wan.. 1 could be pfsense lan, and the other could be opt network.

But according to the docs, WAN is required so is it possible to run pfsense with only LAN and OPT interfaces?

On a separate note, when I cloned the VM, the MAC addresses changed. Can I control the assignment of which mac address is bound to em0 and em1?

update on last week, I didn't have any virtual IPs since I wrongly figured the pfsense could see them both and ping them, but then once I added virtual IPs my 1:1 NAT forwarding started working.

@johnpoz Thank you for all you help.

Thanks for the tip! It appears this still works. Taking a slightly different approach worked for me, too.

I have a dual WAN setup at home and use load balancing (round robin). 99% of services work just fine with this. But I was struggling with the "not at your home location" error on Hulu. I got around it by forcing auth.hulu.com and home.hulu.com traffic out my primary internet circuit. All other Hulu traffic seems to load balance just fine.

If anything the suggestion above will work but you'll need to add the two new domains.

Resolved!

It turned out to be a problem with the NAT outbound rules: By deleting the bridge (its name was set to "LAN") all outbound rules to the Wifi devices have been automatically changed to WAN (they were set to LAN before). However, after setting up LAN1 and OPT1, these rules have to be set manually to the right interface. It was just a coincidence that the https-device was still working as it does not need an NAT outbound rule.

Thread closed ... :-)

Regards,

Volker

DMZ mode, in everything I have seen, is like a 1:1 NAT rule. It forwards all traffic to whatever IP you nominate, in this case pfSense.
So it removes the firewall for that IP but not for other IPs in the routers LAN subnet.

Steve

Thank you johnpoz. I understand what you're saying.

Normally you would have 2 vSwitches, one for WAN and one for LAN. Then you create a pfSense VM with two NICs, one on the WAN switch, the other on the LAN switch. You connect the WAN switch to your physical NIC and your VMs all connect to the LAN switch.

@phil-davis
Have the same situation even removing gw on lan doesn't work. Anything config needed on NAT.

@grimson @jimp true it would appear then that I'm going about this the wrong way. I will re-evaluate my NAT rules and firewall configurations

fixed

Ok I set a SFTP server port 22. Do we need passive port for this too?

Just FIY - there was some sort of a firewall running on the AP on the roof, and after contacting our ISP it was deactivated, and now it seems to work like it should.

Thanks Steve !

Will try to to nat in P2.

cheers, pete

It would not necessarily show in the ARP table unless pfSense has been talking to it directly. The ISP would need to ARP for it and it back to the gateway but that is transparent through the bridge at layer 2.

What exactly is not working? What is working? How are you testing?

Steve

If the wrong server is responding then the wrong server is responding to 10.0.20.7.

Do a packet capture on the inside interface for connections to 10.0.20.7 TCP port 443.

Test a connection in from the outside.

Do you see the SYN going out the local interface? Is it destined for 10.0.20.7? What responds?

You might need to look at the MAC addresses here to see what's really going on.