Larry Moore wrote:
Wolf Geldmacher wrote:
Hi,
I've been using ipfilter for some time now and it has been working for
me quite nicely.
That said, I currently have a problem with ipfilter that I don't know
how
to solve (and yes, I checked the FAQ, the manual pages, googled,
a.s.o.):
I need to *reject* (not drop) outgoing TCP connections on a Solaris 8
box
and I seem to be unable to figure out how to do this up to the point
where I
doubt that it is possible at all.
To reject incoming telnet connections I use a rule like this:
block return-rst in log quick proto tcp from any to any port = 23
pass out quick proto tcp from any port = 23 to any flags R/RSFUP
and it works nicely. To reject outgoing connections I tried:
block return-rst out log quick proto tcp from any to any port = 23
# The use of "return-rst" on "out" rules was a syntax error in
# previous versions of ipf. The current version accepts this without
# complaining.
# The next should not be necessary anyway as the packet never leaves
# the interface. Having or not having this rule does not change the
# behaviour.
#pass in quick proto tcp from any port = 23 to any flags R/RSFUP
This does block outgoing traffic and does log the outgoing SYN packet
but it does not result in a RST packet being returned. Instead the
behaviour seems to indicate that the SYN packet is dropped, resulting
in the usual long TCP connection timeout instead of an immediate
"connection refused".
Is there any way at all to achieve my goal? Where am I going wrong?
The following rule is more effective than "the usual long TCP
connection timeout" though this was done with IP Filter 3.4.35
block out log quick on tun7 proto tcp from any to any port = 23 flags
S/SAFR
bash-2.05b# telnet 10.10.10.10
Trying 10.10.10.10...
telnet: connect to address 10.10.10.10: No route to host
bash-2.05b#
Larry.
I inserted the line you suggested (replacing the interface by my hme0 ;-) but it
does not change the timeout behaviour for me at all, i.e. I still have to wait
3 minutes+.
May I should add that the machine I try to prevent access to in fact does exist
and routing is setup to it? If I try to connect to an non-existing IP I get the
same behavour you get (and fast), but this is independent of the ipf
configuration.
Cheers,
Wolf