Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 2 subscribers
  • Views 3486 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

Disappointed 'bout NAT, MASQUERADING and negated addresses

kkeppler
Hi,

after many years with a PIX 506 we decided to switch to Astaro (ASG-120). The GUI was more self-explaining than Ciscos', and most of all configuration was done without the need to read 1000-paged documents.

But now, after in-depth experience with ASG V7, I'm somehow disappointed. I don't know the "typical" customer of Astaro, but some in my eyes elemental features like negated network definitions (eg. "!192.168.5.0/24") are just missing.

Here's our problem:
We have a LAN (192.168.30.0), connected via IPSEC-VPN with a remote LAN (192.168.40.0).
On the WAN side, we have a small subnet with public IPs (let's call it 1.2.3.0/28).

We want to masquerade most of our LAN->WAN traffic with the external IP 1.2.3.2, but need that some specific LAN hosts masquerade as 1.2.3.3.

After having tried configuring this for several hours, I gave up.

Normal masquerading works fine, but doesn't allow us to use specific public IPs for specific LAN hosts.
SNAT might be a solution, but when building a rule like "SRC Any - DST Any - SNAT 1.2.3.2" also all VPN traffic got SNAT'd (which itself is correct, as I don't have a chance to say "SRC Any - DST !VPN - SNAT 1.2.3.2").
I don't really want to create a host group containing all world-wide networks except my VPN... [;)]

So dear Astaro guys, PLEASE (!!) add a way for negating addresses, and maybe also give some hints on how to configure SNAT/Masquerading with different public IPs.

My research showed that this is indeed an old topic not yet solved:
https://community.sophos.com/products/unified-threat-management/astaroorg/f/54/t/38210
https://community.sophos.com/products/unified-threat-management/astaroorg/f/54/t/38200

Or did I miss something?

Thanks & best regards


This thread was automatically locked due to age.
Parents
  • 0
    Did you try /ipsec/connections/strict routing enabled ?
  • 0 in reply to ClausP
    Did you try /ipsec/connections/strict routing enabled ?


    No, I don't think that this would help in my case. According to the manual, "strict routing" means:

    If strict routing is enabled, VPN routing is done according to source and destination IP address (instead of only destination IP address). In this case, only those packets exactly matching the VPN tunnel definition are routed into the VPN tunnel. [...]



    My problem is, that when using a generic SNAT rule, all packets are routed externally, even those who should go into VPN. Strict routing might help if packets are routed into VPN who shouldn't do so.

    Now all you need is some policy routing to force the traffic you want to hit that other gateway 1.2.3.3 and some SNAT rules to make sure the packets know where to return back to (otherwise return traffic will hit 1.2.3.2).


    Hmm... didn't get very far. My external interface is 1.2.3.2/28 (with default GW 1.2.3.1), and I have an additionall address 1.2.3.3/28. But I can't use that address as a gateway for policy routing (Network -> Routing -> Policy Routes -> New policy route -> Route type: gateway route). The Drag'n'Drop field for "Gateway" doesn't accept the "1.2.3.3 (Address)" entry. (Btw: 1.2.3.3 is displayed with a NIC icon; other manual host adresses showing a server icon were accepted). I can't create another (normal) host entry using that same external IP, I'd have to delete that additional interface first (which would prevent receiving packets for that IP, wouldn't it?).

    However, what would the policy route look like? When I say "Destination Network: Any", again all traffic destinated for the VPN would also match that rule, and be routed through the given gateway.

    Actually I'm not convinced with a policy route + SNAT solution. Is your network setup really that similar to ours? How did you manage to have a machine accessing both the VPN and Internet, while accessing Internet through an "additional address" IP?

    Do you also use ASG V7?

    Thanks in advance!
  • 0 in reply to kkeppler
    I am using SNAT for multiple inside hosts no problem.

    I have a MASQ for INTERNALNETWORK to WANINTERFACE.

    Then I build an SNAT like so:

    TRAFFIC SOURCE - INSIDE HOST
    TRAFFIC SERVICE - ANY
    TRAFFIC DESTINATION - ANY
    NAT MODE - SNAT (SOURCE)
    SOURCE - EXTERNALINTERFACE2

    Now do the above for each host you want SNAT'ed to a different outside IP.

    You can have it auto-create the packet filter if you desire.
  • 0 in reply to ReD-MaN
    TRAFFIC SOURCE - INSIDE HOST
    TRAFFIC SERVICE - ANY
    TRAFFIC DESTINATION - ANY
    NAT MODE - SNAT (SOURCE)
    SOURCE - EXTERNALINTERFACE2


    Yes, that's also what I also tried first. [:)]
    But the problem is: also the traffic for the VPN is SNAT'd here. I'd need a network definition like "TRAFFIC DESTINATION: !VPN_LAN" instead of "ANY" to limit SNAT'ing.
Reply
  • 0 in reply to ReD-MaN
    TRAFFIC SOURCE - INSIDE HOST
    TRAFFIC SERVICE - ANY
    TRAFFIC DESTINATION - ANY
    NAT MODE - SNAT (SOURCE)
    SOURCE - EXTERNALINTERFACE2


    Yes, that's also what I also tried first. [:)]
    But the problem is: also the traffic for the VPN is SNAT'd here. I'd need a network definition like "TRAFFIC DESTINATION: !VPN_LAN" instead of "ANY" to limit SNAT'ing.
Children
  • 0 in reply to kkeppler
    Got it working now [[:)]] I had a look at the iptables and found both a configuration error as well as a workaround for my problem.

    My bug was, that the Host definition of the LAN host being "special" NATed was bound to the internal interface (eth0). The SNAT rule (chain USR_POST in 'nat' table) thus didn't trigger, as it was limited to 'in: eth0'.
    However, the word "bug" is relative, as from the GUI view this isn't obvious.

    After changing the host definition to "any" interface, SNAT worked for it. But still all packets to VPN destinations also got SNAT'ed. So I inserted another SNAT rule before, which avoided SNAT'ing for VPN destinations.
    This would be much easier if we had a way for negating network adresses [[:)]] (I'd only need one rule instead of two).

    According to my example networks, this is my config to SNAT the inside host 192.168.30.55 to the external IP 1.2.3.3 while still accessing the VPN:
    - MASQ is activated (ANY -> External [1.2.3.2])
    - NAT-Rules:
       TRAFFIC SOURCE: 192.168.30.55  ((LAN host))
       TRAFFIC SERVICE: ANY
       TRAFFIC DESTINATION: 192.168.40.0/24  ((VPN Network address))
       NAT MODE: SNAT
       SOURCE: 192.168.30.55  ((LAN host again! no effective SNAT here!)

       TRAFFIC SOURCE: 192.168.30.55  ((LAN host)
       TRAFFIC SERVICE: ANY
       TRAFFIC DESTINATION: ANY
       NAT MODE: SNAT
       SOURCE: 1.2.3.3  ((additional WAN IP))

    (Auto-creation of packet filters activated)
  • 0 in reply to kkeppler
    Hello.  I'll try posting this in this thread.

    Have ASG7 w/ 2 ext ints.

    Ext 1 DG

    Ext 2 is for S2S VPN and Web Publishing to Ext IPs on this link

    Int 1 is my general internal net (192.168.1.x)

    Int 2 is my DMZ net (192.168.21.x)

    Got everything working fine - including the S2S down the second pipe.  But I'm having problems publishing web services.

    I have a MASQs setup...

    1)  Int 1 to Ext 1
    2)  Int 2 to Ext 2

    With this, the machines on my DMZ can browse the net.

    Now I want to publish a service on a DMZ host - let's call it 192.168.21.10.

    As per other threads, I've created the following SNAT :

    TRAFFIC SOURCE - INSIDE HOST on the .21 sub
    TRAFFIC SERVICE - ANY
    TRAFFIC DESTINATION - ANY
    NAT MODE - SNAT (SOURCE)
    SOURCE - An external IP bound to Ext 2

    Then, from a computer outside the firewall, I can't see the published site...

    Thoughts?
  • 0 in reply to dkitch
    I believe the Traffic Source should be ANY, and the destination should be your EXT IP you want to SNAT.
    and the last SOURCE should be the INT/DMZ interface.

    You'll also need a packetfilter rule(s) to allow the incoming traffic.

    Barry