Screen OS

Let me expand on the subject, as thats not very clear.

Basically we have Router -> SSG20 -> LAN. I've configured a number of VIP on the untrusted zone that direct traffic to different servers on the LAN. (for example SFTP, PPTP and two ports 9090 and 81 that have http traffic).

When accessed from 'external' (i.e. anyone on the other side of the router) ip addresses all is well and working correctly.

However when someone on the LAN tries to get the service using the external url I get mixed results: SFTP and PPTP both work, but the 9090 and 81 work but stylesheets are disabled and some other weird behaviour.

Looking at the log file on the policy of the SSG20 the 9090 and 81 when accessed internally results in a Close - TCP RST.

Any ideas?

The configuration of the SSG20 is pretty simple. One untrusted zone, with one port to the router. One trusted zone with three ports to the LAN. VIP is configured on the untrusted zone, and a policy has been created for each of the VIPS. - Like I said externally everything looks dandy,.. just the internal calls (by the way if the internal calls use the local ip addresses they work!).

Regards

I would convert the vip into a policy based nat.  And then for the trust connections going to the internal server perform both a source and destination nat on the traffic.

The reason you may see the inconsistent behaviour is that the server and client are in the same subnet so they do some of their communications at layer 2 bypassing the firewall.  this causes the sessions to be incomplete and close with a reset.

I have a configuration sample posted in the library forum for this scenario.

http://forums.juniper.net/t5/Configuration-Library/Server-published-to-Public-IP-for-both-Trust-amp-Untrust/m-p/98018#M254

Hi Steve,

Thanks for your response. I've tried following the example that you've given and am so far unsuccesful.

Basically the external IP address on the router is 83.x.x.x but the router is sending all traffic to 192.168.18.2 (which is the IP address assigned to ethernet0/0).

The problem is that when I run the command to do the proxy arp (which I believe using the example should be set interface ethernet0/0 proxy-arp-entry 192.168.18.2 192.168.18.2) I get a failed message saying there is a conflict with a management port. What's weird here is that there should be no management on 192.168.18.2?!?!? I've checked with the WebUI and ethernet0/0 has the management unticked...

Any suggestions welcomed,... regards

The example was for using an ip address not on the actual interface but in the same subnet.  In that case proxy-arp is needed.

If the address you are using is the interface address, then no proxy-arp is necessary as the interface will do the actual arp because it owns the address.

Hi,

Thanks for that, using your example and the note about the proxy-arp I seem to have configured it to work correctly - well it works whether it is the best mechanism or not I don't know.

Cheers