Not working POSTROUTING replace source address

[lioncub@…]

Not working in "Port Forwarding" checkbox "Replace source address". In checked or unchecked not change ip address.

[cperez@…]

Hi lioncub, and thank you for your report. I think you misunderstood the feature. That checkbox is not intended for change the source address in the GUI.

It is intended to create a NAT rule on that port forwarding, so the destination machine will be able to reply packages without the route of the original source.

[nomad@…]

This bug is still around. I NAT my port 25 to a postfix server. The Postfix server only shows the firewall IP as connected client. Disabling the "replaces source IP" doesn't solve the problem. Older Zentyal versions are working OK.

[cperez@…]

Hi,

I've just tested this and it works for me, please reopen if you can provide more info and a detailed guide on how to reproduce this

Best regards

[nomad@…]

I created a NAT rule for port 25 to the server. I changed the rule so the option Replace source IP is disabled. I do "tail -f /var/log/mail.info" on the postfix server.

Next, I use telnet from a remote IP to the server. The mail.info log comes with: Oct 28 14:08:54 zarafa01 postfix/smtpd[27083]: connect from ns.check-ict.local[10.10.1.1] Oct 28 14:08:54 zarafa01 postfix/smtpd[27083]: NOQUEUE: reject: RCPT from ns.check-ict.local[10.10.1.1]: 554 5.7.1 <test@…>: Relay access denied; from=<supertool@…> to=<test@…> proto=SMTP helo=<please-read-policy.mxtoolbox.com> Oct 28 14:08:55 zarafa01 postfix/smtpd[27083]: disconnect from ns.check-ict.local[10.10.1.1]

If I want to allow mxtoolbox to relay from my server, I would normally add this IP in my trusted network in the postfix config. Now I can only add 10.10.1.1 to my trusted network, wich means that the whole world can use my server as relay.

[jamor@…]

Hello lionclub, which source NAT addres you used?. It is only used if it is an address which could be foound in one of your internal networks. If not, this parameter is ignored.

We cannot check this in the web page because the IP cou; change if one of the local interfaces has DHCP.

[jamor@…]

Hello Nomad, why do you don't put a source address replacement so you can add always the same IP to your trusted networks. You should choose one from any of the internal networks connected to the Zentyal servers.

[jamor@…]

Since it seems that this was a configuration problem (not using a local network IP), I close this.

If I am wrong, don't hesitate to reopen the ticket.

[nomad@…]

My config is: WAN IP (95.211.X.X) -> LAN IP (10.10.1.X) NAT Port 25 Disabled option "Replace source address"

On the same Zentyal box, I created a extra WAN IP. I made the same firewall configuration and this one works. Still I wonder why the default WAN IP isn't working...

[montiwall@…]

Hi all,

I can confirm similar behavior in 2.2.4 using X port on external eth1 forwarded to "Same" port on internal Y server on eth0 does not respect unchecked "Replace source address".

Suffice it to say that I tried a wide range of things in the UI and elsewhere to get this working.

What worked was to uncheck all other port forwarding entries' "Replace source address".

Now correct source addresses appear to applications.

Seems to be some crosstalk in firewall chain port forwarding entries with respect to "Replace source address".

[cperez@…]

Hi montiwall, I have been trying to reproduce this, but it works for me :S

Can you explain your rule and post here the result of these commands?

iptables -n -v -L fredirects iptables -t nat -n -v -L POSTROUTING

Thank you for your feedback, Best regards

[montiwall@…]

Happy to provide details, but would prefer a private communication due to information in the output.

Can I send details to your zentyal.com address?

[cperez@…]

Yes please:

cperez (at) zentyal.com

[cperez@…]

Did you send anything? I'll keep this ticket waiting for that :)

[montiwall@…]

Have not sent yet.

I figure you need the error condition active before iptables -L, and also need my live context in order to verify the error state. Need to schedule some downtime, and we're a little busy at the moment.

Will do it as soon as possible. Hopefully before the weekend.

[cperez@…]

Sorry, but I couldn't reproduce this, please reopen if you can provide the dump

[niladam@…]

I can confirm this bug.

For some reason, if you have multiple forwards to a LOCAL network IP (4 for example) and two are selected to REPLACE SOURCE ADDRESS and TWO are NOT, the last two are NOT working. On the target IP the connecting appears to be the local zentyal IP.

[niladam@…]

So just for heads up, to reproduce follow these steps based on this scenario:

Scenario: Local Network with Zentyal as gateway (192.168.0.1 for example) - no other gateway!

1. Create a forwarding for port 5900 (vnc port) to point to a local IP in the network - Let's say 192.168.0.100. Make sure you TICK the REPLACE SOURCE ADDRESS.
2. Create another forwarding for a different port, let's say 5800 to the same IP (192.168.0.100). Make sure you DO NOT tick the REPLACE SOURCE ADDRESS.
3. The replacing should actually take for BOTH of the forwardings.

[jamor@…]

Thanks for your detailed report, Nidalam.

We are looking to the issue.

[jamor@…]

We have changed the redirects rules in [a065228] to try to avodi this problem.

Do you want to try it?. To do so:

1. Download the new version of IptablesRedirectRule?.pm from  http://git.zentyal.org/zentyal.git/blob_plain/a065228b2c62e3fc9db41721a260d88e4d243983:/main/firewall/src/EBox/Firewall/IptablesRedirectRule.pm
2. Use it to replace /usr/share/perl5/EBox/Firewall/IptablesRedirectRule.pm
3. Restart web console module: "sudo /etc/init.d/zentyal apache restart"
4. Restart firewall module: "sudo /etc/init.d/zentyal firewall restart"

Please, reopen if this new version does not fix the redirects problems.

Regards,

Javier

[sircompo@…]

Hi Javier,

I'm experiencing the same issue and am keen to implement your fix.

Is [a065228] a resource that can be accessed publicly (e.g. a source code commit) ? Apologies if I'm missing something obvious, but I can't find what it refers to.

Also, where can the new version of IptablesRedirectRule?.pm be downloaded from ?

Many thanks, Dave.

Replying to jamor@…:

We have changed the redirects rules in [a065228] to try to avodi this problem.

Do you want to try it?. To do so:

1. Download the new version of IptablesRedirectRule?.pm from
2. Use it to replace /usr/share/perl5/EBox/Firewall/IptablesRedirectRule.pm
3. Restart web console module: "sudo /etc/init.d/zentyal apache restart"
4. Restart firewall module: "sudo /etc/init.d/zentyal firewall restart"

Please, reopen if this new version does not fix the redirects problems.

Regards,

Javier

[jamor@…]

Sorry but the GIT link is not working for some reason . The full link is  http://git.zentyal.org/zentyal.git/commit/a065228b2c62e3fc9db41721a260d88e4d243983

I will fix the previous message with the address of the IptablesRedirectRule?.pm for this commit, which is  http://git.zentyal.org/zentyal.git/blob_plain/a065228b2c62e3fc9db41721a260d88e4d243983:/main/firewall/src/EBox/Firewall/IptablesRedirectRule.pm

[lancebrian@…]

Okay guys, did download the patch but still unable to port forward. For example if my Zentyal gateway is eth0:41.222.196.108 (public) and eth0: 172.16.10.1(internal) and my internal server behind zentyal server is 172.16.10.6

How do i port forward 172.16.10.6:120 so it accessed external as 41.222.196.108:120.

Have created a service for port 120 and also created " Accept" port traffic from " external to zentyal " in firewall but nothing works.

If you got a set by step process, of portforwarding that works in my scenario Please give a hint.

Thanks.

[sircompo@…]

I applied the patch and restarted the services, but all forwarding seemed to stop dead. As it's on a production system I reverted back to the previous version for now, and will try again later. I'm guessing (well, hoping) that perhaps it's necessary to remove all existing port forwarding rules and recreate them. I probably won't get a chance to try it for a couple of days.

Lance ; in theory you just need to set the source IP as any and the source port as 120, and the destination IP as 172.16.10.6 and the destination port as 'Same'. Then untick the 'replace source address' option. If the patch is working it should be that simple. So far as I'm aware, no firewall rules are required in this instance, but that may not be the case if other changes have been made to the firewall configuration (e.g. a default rule that blocks all WAN to LAN traffic).

Hopefully Javier will be able to replicate the problem and retest his solution. (thanks Javier - we appreciate your help !)

Dave.

Replying to lancebrian@…:

Okay guys, did download the patch but still unable to port forward. For example if my Zentyal gateway is eth0:41.222.196.108 (public) and eth0: 172.16.10.1(internal) and my internal server behind zentyal server is 172.16.10.6

How do i port forward 172.16.10.6:120 so it accessed external as 41.222.196.108:120.

Have created a service for port 120 and also created " Accept" port traffic from " external to zentyal " in firewall but nothing works.

If you got a set by step process, of portforwarding that works in my scenario Please give a hint.

Thanks.

[lancebrian@…]

Well it worked fine except , Cannot access internal server using the public IP when on internal LAN computers. However Outside my network, can access port forwarded server.

[sircompo@…]

It's reassuring to hear it's working. I'll probably give it another shot in the morning.

Regarding public ip access, I've used split DNS to overcome that in the past. As for what causes it, I've never put much time into figuring it out (this was a different setup altogether ; no Zentyal). If necessary I'd use wireshark to see where the packets are going astray. If it is (as you suggested) just down to a simple firewall rule it wouldn't surprise me.

[sircompo@…]

OK, seems to be working on second attempt. Thanks Javier.