Questions about nat/port forwarding

[Juve]

Hi all,

I'm currently under a migration between a Linux iptables firewall and a pfSense box. In the old firewall (iptables) there are some rules I do not know how to copy them to pfSense.
It is all about NAT/port forwarding.

First one :

There is a rule that do a DNAT from one subnet to a single IP on any TCP port. For example : 
                  all TCP packets coming from 123.123.123.0/24  directed to 234.234.234.234 are forwarded to internal IP 10.10.10.10

Can I use 1:1 NAT for doing that, I agree that the source will have to be a single host for making a /32 mapping, is there a way for doing MANY to ONE (inbound)?

Second one:

There are two rules forwarding the same port on two different hosts from a single public IP and all of that based on the IP address of the source host. For example
My public IP is 123.123.123.123
Mr X got IP 456.456.456.456 and Mr Y got IP 789.789.789.789.
When Mr X wants to connect to port 22 on my public IP, it is forwarded to internal host 10.10.10.10
When Mr Y wants to connect to port 22 on my public IP, it is forwarded to internal host 20.20.20.20

How to do that ? I know PF have the ability of doing that with the "from" field of a RDR rule. This type of feature is really useful but I could not do it with pfSense, am I stupid ?

Thanks a lot for all your answers.

[Juve]

oops I posted it in the wrong section, can an admin move this post to NAT section…. really sorry I posted it too late in the evening.

[Juve]

No one wants to give me an answer ? :'( :'( :'( :'( :'( :'( :'( :'(

[hoba]

@Juve:

Hi all,

I'm currently under a migration between a Linux iptables firewall and a pfSense box. In the old firewall (iptables) there are some rules I do not know how to copy them to pfSense.
It is all about NAT/port forwarding.

First one :

There is a rule that do a DNAT from one subnet to a single IP on any TCP port. For example : 
                  all TCP packets coming from 123.123.123.0/24  directed to 234.234.234.234 are forwarded to internal IP 10.10.10.10

Can I use 1:1 NAT for doing that, I agree that the source will have to be a single host for making a /32 mapping, is there a way for doing MANY to ONE (inbound)?

In case 234.234.234.234 is is not the real Interface IP you need a VIP for this IP first. Then you can decide wether you do a portforward for this interface of tcp range 1-65535 to 10.10.10.10 or do a 1:1 NAT. In the firewallrule for this NAT make sure only source 123.123.123.0/24 is allowed.

@Juve:

Second one:

There are two rules forwarding the same port on two different hosts from a single public IP and all of that based on the IP address of the source host. For example
My public IP is 123.123.123.123
Mr X got IP 456.456.456.456 and Mr Y got IP 789.789.789.789.
When Mr X wants to connect to port 22 on my public IP, it is forwarded to internal host 10.10.10.10
When Mr Y wants to connect to port 22 on my public IP, it is forwarded to internal host 20.20.20.20

How to do that ? I know PF have the ability of doing that with the "from" field of a RDR rule. This type of feature is really useful but I could not do it with pfSense, am I stupid ?

Thanks a lot for all your answers.

pfSense can't do NAT based on the source IP, at least it is not supported by the gui and manually edited/added rules will be overwritten sooner or later if the ruleset is regenerated (reboot, rulechange at gui,…).

[Juve]

Thanks for the first answer !!! it works fine  ;D

For the second one, would it be easy to add a module allowing "customized" rules that would be inserted in the ruleset each time the rules are generated ? I know it has to handle order since nat and rdr have to be placed at the begining and this may cause problems….
Why pfSense isn't supporting source adress based NAT? is it a choice you made at the beginnig of the project or is there a technical limit that forces you not to do it ? I didn't take a look a the code generating the ruleset, i will do it to see if it can easily be modified to allow the from statement in a RDR rule.

Many many many....many thanks  ;)

[hoba]

Maybe a 1.1 feature, but don't take this as a promise. However (like always) patches accepted.