Masquerading effective although not configured

What protocol are we talking about?  If it's HTTP/S ... then maybe your proxy is enabled?

Hello BrucekConvergent,

thanks for your reply. Actually it's all the same no matter which protocol i use. Tested it for http, cvs, svn.

But there is no proxy in the way anyway...

Cheers

Hi, xorxy, and welcome to the User BB!

Like Bruce, I know that it's not possible to have this happen in an Astaro unless there's a masq rule, an SNAT rule or the traffic is passing via a proxy.

On the dashboard, what 'Subscriptions' show as active?  What evidence do you have that "outbound requests initiated from one of the internal servers leave the firewall with the IP-address of the external firewall-NIC"?

Cheers - Bob

Hmmm...

Odd, but ok - so obvious the WAN interface has internet access, and so does aparently the internal interface as well which wouldn't really be possible unless it masq. on the WAN and likely have a firewall rule allowing it access to "any" or as Bob states.

However, if the internal servers public IP's is in the same range as the WAN IP scope/range and traffic between internal and "any" is allowed in the packet filter I do believe this could be possible especially if you set the servers gateway to the wan IP.
I know its a little longhaired, but this would if the theory holds force the ASG to actually send packages out rewriting them to WAN Public IP.

That being said, only a few things require a public routeable IP - one of them being microsoft communications server in previous version. Now it supports both NAT and reverse proxy as far as I can recall.
The only way you can archieve what I think you are trying to do is to either break up your public scope and have part if it routet towards your WAN IP where you handle everything your self - meaning there wont be a ISP gateway for that range. But you waste some IP's on that account.
Another way is to have a internal transfernet and routing....

But as Bob says.. show us what you got. And please also IP examples without compromising the real ones, and firewall rules.

Hello you all,

thank you for your time again.

1) Basically this is a testbed for a simple firewall protecting a couple of servers which i can't reverse-proxy for some reasons, thus i'll have to stick with public addresses.

2) All involved servers are member of a class C, resembling the following scenario ("real" IP addresses actually are public IP-addresses):

ASG8-internal:192.168.0.65
ASG8-external:192.168.0.137

Server under scrutiny: 192.168.0.90

3) Phenomenon: any outbound cvs session to a WAN based server started on 192.168.0.90 results in traffic that can be sniffed outside the ASG as a connection (attempt) like:

"192.168.0.137:35082 => ***.***.***.***:2401"

... while i expected it to be:

"192.168.0.90:35082 => ***.***.***.***:2401".

Same behaviour applies when simply telnetting 2401.


4) Iptables listed on console of ASG doesn't tell any utilization of SNAT/DNAT, but the following snippet related to the issue:

iptables:

>>>
Chain USR_FORWARD (1 references)
[ ... ]
    0     0 LOGACCEPT  tcp  --  eth0   eth1    192.168.0.90        ***.***.***.***       tcp spts:1:65535 dpt:2401 policy match dir out pol none LOGMARK match 33 
    0     0 LOGACCEPT  tcp  --  eth0   eth1    192.168.0.90        ***.***.***.***       tcp spts:1:65535 dpt:5306 policy match dir out pol none LOGMARK match 34 
    0     0 CONFIRMED  tcp  --  eth0   eth1    192.168.0.90        ***.***.***.***      tcp spts:1:65535 dpt:25 policy match dir out pol none 
    0     0 CONFIRMED  tcp  --  eth0   *       192.168.0.90        0.0.0.0/0           tcp spts:1:65535 multiport dports 8080,80,3128,443 policy match dir in pol none 
[ ... ]    

Chain USR_OUTPUT (1 references)
 pkts bytes target     prot opt in     out     source               destination
[ NOTHING/EMPTY ]

Seems like a strange issue. One thing to note is that ASG does not like to have more than one interface defined in the same network, as it looks like you have it setup as both internal and external are 192.168.0.0/24. If you want more than one interface in the same network then it is suggested you bridge the interfaces. Since this is a test environment you could try changing one of the interfaces so they are not in the same network and see if it behaves the same.

Please post anonymized output of 'iptables -L -t nat', entered as root at the ASG.

BTW, just to clarify: There is no problem with having multiple IPs assigned to different interfaces that are in the same subnet. ASG behaves like any other OS would do in that case, nothing special. But: No routing is possible/necessary between those interfaces with such a configuration.

For your setup, bridge mode is really necessary. OR you create additional subnets from your existing subnet.

Hello you all,

this is quite embarrassing now [:$], since the solution was very simple. Obviously a simple restart did the trick - after having deactivated that masquerading rule which had been created by the installation wizard. I'm simply not used to restart a machine in order to make configs effective and thats why i didn't consider it.

After having restarted the ASG behaved perfectly as expected.

I must stress here i did NOT had to restart the ASG while reconfiguring it any other time so far, this time was obviously the exception to the rule.

Sorry for all the fuss.

@ trollvottels argument about bridging required here: i forgot to mention that all hosts involved are located in a /26 subnet here, which should do the job, i guess?

Thank you all for your involvement,

Cheers