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

"NO NAT" not effective - ASG8.30

xorxy
Dear community,

i'm running an ASG8.30 as a proxy, catching all intranet host's outbound http-access, including access to webservers located in our DMZ (exterior to our proxy).

The proxy runs in "standard mode" by intention.

The targeted webserver is a development project and only selected internal hosts should be allowed to access it, and when doing so, their original private IP-addresses should show up in the webserver's logfiles. Nevertheless the webserver has (and should keep) a public IP-address since public access should be possible principially.
Initially the private host was bound to internal proxy interface only, changing that to "all" interfaces did not help the problem.


a) Assumed this constellation makes sense, all it takes is to except http access of those selected intranet-hosts to that DMZ-webserver from NATing (while webfiltering still is wanted) while all other http-access of these clients to all other public hosts still should get fully proxied.

My attempt to use a "No Nat" rule like this:

No NAT [Access www-Server] "Internal-External"
Traffic selector[:P]rivate-host=>HTTP=>DMZ-web-server
Automatic Firewall rule:yes
Initial packets are logged:yes

... does not work at all: the webserver's logfile still has the proxy's external interface's IP-address.

b) Another attempt via a SNAT rule using the private address as the new address also failed silently.

c) Even more strange:

Setting a catch-all-logging-firewall rule "private-host=>ANY&LOG=>DMZ-webserver" at position "1" unveils that only the ASTARO-webadmin-access from that private-host (port 4444) is logged, while access to "DMZ-webserver-site:80/" is NOT logged at all.

This looks like this access does not enter iptables at all, instead it passes entirely through webproxy?!?




Thus my question:

1) Is this possible at all with ASG8.3?
2) Does the websecurity-facility have preference over the iptables-facility?

I know: running the website on a custom port would be an easy fix, but i'm interested in understanding the inner workings and also prefer to manage all client-access centrally with our proxy facility (for managment reasons, multiple admins, ...).

If anyone of you could explain that i certainly would appreciate it.

Cheers!


This thread was automatically locked due to age.
  • 0
    Please show a simple diagram with representative IPs. Have you tried to change Proxy Settings in the client to bypass the Proxy for this server?  You also would need a Firewall rule to allow the traffic through the Astaro. 

    Cheers - Nob

    Sorry for any short responses!  Posted from my iPhone.
  • 0
    Hi again,

    having spend another day all i cropped up so far is a bit more insight and a mounting suspicion this simply can't be done with ASTARO, at least as long you do NOT "transparent proxy".

    1) My assumed "easy fix" by simply using a custom port for http does NOT work: same behaviour as with http over 80. I could have known, it's the protocol, stupid...

    2) Trickery with 
    - configuring a virtual NIC on the proxy's external IF and 
    - giving it a public address from the subnet the proxy's external IP-address is located and 
    - adding as SNAT-rule that rewrites the private intranet-host's IP-address to that official "virtual" IP address does not work at all, still all outbound traffic is labeled as stemming from the proxy's external IP-address.

    3) All i need is nothing but what ASTARO ASG 8.3 is able to do for private IP-addresses when configuring network ACLs allowing intranet hosts WebAdmin-access to ASTARO gateways on the other side of the proxy identified by private IP-addresses: that works brilliantly => why not the same for custom services?!? Or can that be done?

    Looks like ASG 8.3 is no solution for me, i need network ACLs...

    Anyone an idea how compensate for that (besides rearranging my entire network topology)?!?

    Still highly appreciating any proposal.

    Cheers again...
  • 0
    Hello Balfson,

    that was close ;-) - read your post directly after my last post...

    Here my basic topology, scetched with humble means:

    [WAN][Firewall][(DMZ)   [WebServer-public]][ASG8.3-proxy][intranet-private-IP]

    Inside the intranet a host that should be granted access to WebServer via http (80 or custom) on base of that host's private-IP. This private IP should also make it into the webserver's log-files.

    I thought this scenario could quite well be handled using a "No NAT"-rule...

    A corresponding firewall-rule was configured, including "log"-option and traffic actually passed the firewall, but always hit the webserver with the proxy's external IP-address.

    Deactivating the proxy in my local firefox on my accessing client blocked all the internet access (to my understanding due to non transparent proxy).

    Thanks for your reply,

    cheers!
  • 0
    This should be easy, but you can't use the Astaro Proxy as the source IP always will be the IP of "External (Address)" - you must add the public IP and the FQDN of the server to 'Exceptions' in the 'Proxy Settings' of your PC.

    I don't know if the NONAT will work in this situation; if it does prevent the traffic from being masqueraded by 'Internal (Network) -> External', that would be interesting to know.  If it doesn't work, then the SNAT you described will work.

    The final trick is to put a route into the webserver for the 10. traffic so that it doesn't send its responses to its default gateway.

    Is it working now?

    Cheers - Bob
  • 0 in reply to BAlfson
    Hello BALFson,

    thanks again for your help.

    O.k., this is ridiculous. My entire crusade started with the obvious method to fail: making a proxy-exception in the client config (browser). After the alternate attempts failed and you posted this client-focused method should work, i returned to where i started and scrutinized, why the client thing actually failed.

    It turned out that i deactivated the proxy-access in my client's firefox, but on a machine that is MCX-managed via OD. For a reason i don't know yet that MCX-config (that also governs all MCX-lients network config) still superseded the local clients settings, which is perfectly fine actually, but i always thought it only applies for SAFARI, while firefox still is sort of independent in terms of MCX-connection-management.

    The bottom line:

    Configuring a proxy exception for the targeted host locally in the client or in the client's management plus configuring "NoNAt" under "NetworkSecurity>DNAT/SNAT" together with "Automatic Firewall rule" does the job perfectly now - at least for HTTP.

    For HTTPS the problem still persists, probably because the proxy (webfilter) still captures all HTTPS traffic (?!?). 

    -Using the same config as worked for HTTP plus 
    -creating an exception under "Websecurity>Webfilter>Exceptions" by checking "on" all the filter options in order to deactivate them 
    did not the trick yet.

    I'll digg deeper here and return if i have the solution.

    So long

    Ahoi
  • 0
    -creating an exception under "Websecurity>Webfilter>Exceptions" by checking "on" all the filter options in order to deactivate them did not the trick yet.

    When the client is configured for Astaro Proxy "Standard" mode, there's nothing you can do in Web Security that will solve your issue; any traffic handled by the HTTP Proxy will leave the Astaro with the IP of "External (Address)".

    Cheers - Bob
  • 0 in reply to BAlfson
    Hello Bob,

    i still suspect i might not have understood the concept completely: i thought i could have https-access bypassing the proxy for specific hosts with the same method i used successfully for HTTP:

    - i deactivate the proxy in the client-browser's entirely (> also for https) and configure an iptables rule to allow that (for that client).
    - i then configure the same NoNAT rule as i did for HTTP, i think the NATing should be deactivated for HTTPS? Or may the currently active SSL-scanning interfere somehow?

    But still all https-traffic hits my DMZ-server with the proxy's external IP-address

    zefix!

    So long and thanks again...