>From: Daniel Baldoni <[EMAIL PROTECTED]>
>Date: Wed, 03 Apr 2002 12:54:33 +0800
>
>G'day folks,
>
>I have a client who has the misfortune of running SunScreen 2.0 (under
>Solaris 2.6) - a configuration I've not seen in over 3 years. Until now, the
a classic ;-)
[...]
>Until now, the client has never had any "through" services working (i.e. no
>pings, telnets, anything) from LAN workstations (which is what they wanted).
>Now, however, they have a piece of custom software which needs to talk to a
>remote service on a tcp high port (6080). Here are the steps I went through
>to try and get it working:
>
> 1. Defined the service as:
> ss_service default add <svc> SINGLE { { tcp { { 6080 } } } }
> 2. Defined the remote address:
> ss_address default add <addr> HOST w.x.y.z "<comment>"
> 3. Added a rule:
> ss_rule default <config> add <svc> <add1> <addr> ALLOW \(
> LOG_SUMMARY SNMP_NONE \)
> <add1> was already defined as their local LAN network (i.e.
> 192.168.1.0)
> 4. Compiled and activated the new policy:
> ss_compile_and_activate default <config>
>
>The result was a series of "Denied or no pass rule" entries in the log
>whenever we tried to establish a connection. A rule allowing the same service
>from the firewall to the remote server works flawlessly.
>
>I believe my first mistake was in not adding NAT to the equation. As
>the connection is "direct" between the workstations and the big bad Internet,
>RFC1918 addresses are a no-no. So, I tried adding a NAT rule dynamically
>allocating a.b.c.244 to the internal LAN with appropriate changes to the
><add1> value in the rule at step 2 above. The result of this was "Logged
Note: with SunScreen NAT, you always write the packet filtering rules
with the *private* address. This is true for all versions of SunScreen
(even though NAT was mostly revised between 2.0 and 3.0 releases),
so you actually did not want to change your rule, it should still
be defined with the private local LAN as the src addr.
SunScreen EFS 2.0 NAT had quite a few "gotchas" when it shipped, so
make sure they have the latest 2.0 patch (currently 106881-03, released
back in 1999, so I'm sure they already have it ... :).
Also, make sure you have a proxy ARP entry for the public IP address
you are using on the Screen. (you should add this to a startup script,
so it is persistent between reboots).
>passed packet" entries in the log, but apparently broadcast packets coming
>back from the remote server being blocked (they used the appropriate source
>and destination ports but with a destination address of 255.255.255.255).
Nothing about your service or your rule allows for this scenario. As
a stateful packet filter, EFS 2.0 expects the response packets to match
the IPs (well, reversed) of the initial connection that was allowed, but
this server is sending a broadcast packet in response.
It's been a long time since I've used a 2.0 system, but you should be
able to expand your service to include a REVERSE ... BROADCAST filter
(see some existing services for examples of how to do this, I won't
even try to get the number of brackets correct without a system to
try it on), that should catch the response.
Valerie
--
Now appearing as "Gertie" in Sunnyvale Community Player's Oklahoma!
April 12 - May 5, 2002. Details: http://www.sunnyvaleplayers.org/
_______________________________________________
Firewalls mailing list
[EMAIL PROTECTED]
http://lists.gnac.net/mailman/listinfo/firewalls
