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

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.
Parents
  • 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
Reply
  • 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
Children
  • 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