Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 2 subscribers
  • Views 2115 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
    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.
Reply
  • 0
    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.
Children
  • 0 in reply to Vels
    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 ]