Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 2 subscribers
  • Views 2111 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Masquerading effective although not configured

xorxy
Dear Others,

i'm running an ASG8 meant to be a plain firewall in a very simple topology:

- external firewall-NIC headed towards WAN, 
- internal firewall-NIC protecting a bunch of servers, each of which featuring public & routable IP-addresses.

Thus no need for sporting any sort of NAT here => no NAT configured by me, nor having any masquerading rules in place.

Nevertheless (and here it gets creepy):

All outbound requests initiated from one of the internal servers leave the firewall with the IP-address of the external firewall-NIC, which looks very much like masquerading (if not IS masquerading, right?), while i prefer them to have the source-IP-address of the respective requesting machine.

Listing the current iptables rules on firewall-commandline does not exhibit any DNAT/SNAT rule, just plain firewalling.

What is going on here? Maybe some automagic features of ASG8 i missed to consider?

Did i fundamentally misunderstand the entire concept?

Any hint is highly appreciated, thanks in advance

X


This thread was automatically locked due to age.
Parents
  • 0
    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.
  • 0 in reply to trollvottel
    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
Reply
  • 0 in reply to trollvottel
    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
Children
No Data