UDP server on multihomed host; client behind packet filter

This is a discussion on UDP server on multihomed host; client behind packet filter within the IPFilter forums, part of the System Security and Security Related category; --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable First off, I'd ...


Go Back   Usenet Forums > System Security and Security Related > IPFilter

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 07-10-2003
Ryan Beasley
 
Posts: n/a
Default UDP server on multihomed host; client behind packet filter


--IJpNTDwzlM2Ie8A6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

First off, I'd like to apologize if this has been covered before.
(I haven't found anything in the Google Groups archive or the list
archive at marc.theaimsgroup.com. A quick run through the sources
didn't reveal anything, either.)

I was wondering how y'all handle UDP servers bound to INADDR_ANY
on hosts multihomed to the same network. It's completely conceivable
for reply datagrams to be sent from an address/port not matching
the client's original destination, thus failing tests in that NAT
and/or state code.

Assume the following:
I don't control the servers and can't force them to use a socket
on each address. (I wouldn't want to waste sockets like that,
either.) The client program doesn't care about the reply's source
address and port.

Knowing the service port ahead of time, I could hack IPF, adding a
"wild" flag, and write a rule specific to this port that'd cause the
state and NAT code to make use of wildcard flags. Thoughts?

e.g.,
pass out quick on xl0 proto udp from any to \
192.168.0.16/28 port =3D 1723 keep state keep frags wild_daddr
=20
I don't want to go so far as permitting all traffic from the
server subnet + port to all of my clients.

Is there an elegant and seemingly obvious solution that I'm
(prone to) overlooking?

As always, any information is appreciated.

--=20
ryan beasley <ryanb@goddamnbastard.org>
GPG ID: 0x16EFBD48

--IJpNTDwzlM2Ie8A6
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (FreeBSD)

iD8DBQE/DLzUskfdOxbvvUgRAkZVAJ4gy+FBy9gamjmH9ScaiBTDDkRV+A CgmMEY
jKYeamqn3fsHKYmJeH0m/fc=
=ex8M
-----END PGP SIGNATURE-----

--IJpNTDwzlM2Ie8A6--
Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are Off
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT +1. The time now is 09:53 PM.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO 3.0.0