[pfSense Support] DNS cache poisoning

2008-07-21 Thread sai
checkpoint firewalls seem to have a problem in not randomising (or
even de-randomising) dns request source port [1]

do we have a similar problem with pfSense?
I did 3 digs to  198.6.1.1, 198.6.1.2 and 198.6.1.3  ( I have  2 isps,
load balanced)

pfctl -ss  (to see the states)

self udp 10.60.60.10:33306 - a.b.c.d:51192 - 198.6.1.1:53
MULTIPLE:SINGLE
self udp 10.60.60.10:33306 - e.f.g.h:57512 - 198.6.1.2:53
MULTIPLE:SINGLE
self udp 10.60.60.10:33306 - a.b.c.d:56970 - 198.6.1.3:53
MULTIPLE:SINGLE

self udp 198.6.1.1:53 - 10.60.60.10:33306   SINGLE:MULTIPLE
self udp 198.6.1.2:53 - 10.60.60.10:33306   SINGLE:MULTIPLE
self udp 198.6.1.3:53 - 10.60.60.10:33306   SINGLE:MULTIPLE

looks like my (linux) box is sending source only set to port 33306
(bad linux, bad) but pfSense is randomising it just fine. yes I know
that this is not a statistically valid data set, and the port range is
quite limited, but it looks ok.

could one of the devs confirm that dns cache problem is mitigated ?

sai

refs:
[1] http://seclists.org/fulldisclosure/2008/Jul/0104.html
[2] http://blog.spoofed.org/2008/07/mitigating-dns-cache-poisoning-with-pf.html
[3] https://www.dns-oarc.net/oarc/services/porttest

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [pfSense Support] DNS cache poisoning

2008-07-21 Thread Scott Ullrich
On Mon, Jul 21, 2008 at 4:58 AM, sai [EMAIL PROTECTED] wrote:
 checkpoint firewalls seem to have a problem in not randomising (or
 even de-randomising) dns request source port [1]

 do we have a similar problem with pfSense?
 I did 3 digs to  198.6.1.1, 198.6.1.2 and 198.6.1.3  ( I have  2 isps,
 load balanced)

 pfctl -ss  (to see the states)

 self udp 10.60.60.10:33306 - a.b.c.d:51192 - 198.6.1.1:53
 MULTIPLE:SINGLE
 self udp 10.60.60.10:33306 - e.f.g.h:57512 - 198.6.1.2:53
 MULTIPLE:SINGLE
 self udp 10.60.60.10:33306 - a.b.c.d:56970 - 198.6.1.3:53
 MULTIPLE:SINGLE

 self udp 198.6.1.1:53 - 10.60.60.10:33306   SINGLE:MULTIPLE
 self udp 198.6.1.2:53 - 10.60.60.10:33306   SINGLE:MULTIPLE
 self udp 198.6.1.3:53 - 10.60.60.10:33306   SINGLE:MULTIPLE

 looks like my (linux) box is sending source only set to port 33306
 (bad linux, bad) but pfSense is randomising it just fine. yes I know
 that this is not a statistically valid data set, and the port range is
 quite limited, but it looks ok.

 could one of the devs confirm that dns cache problem is mitigated ?

 sai

 refs:
 [1] http://seclists.org/fulldisclosure/2008/Jul/0104.html
 [2] 
 http://blog.spoofed.org/2008/07/mitigating-dns-cache-poisoning-with-pf.html
 [3] https://www.dns-oarc.net/oarc/services/porttest

See http://blog.pfsense.org/?p=210

Scott

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [pfSense Support] DNS cache poisoning

2008-07-21 Thread Chris Buechler

sai wrote:

checkpoint firewalls seem to have a problem in not randomising (or
even de-randomising) dns request source port [1]

do we have a similar problem with pfSense?
  


No, pf has randomized source ports on all NATed TCP and UDP traffic for 
8 years. I was surprised to find out that's the exception rather than 
the norm. Cisco, Checkpoint, amongst numerous others apparently do not 
randomize source ports on NATed traffic.


The net result of this is if your DNS servers are behind pfSense, you 
could very well be protected from all this DNS noise of late even 
without patches. For the DNS forwarder running on pfSense itself, see 
http://blog.pfsense.org/?p=210



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[pfSense Support] kernel: vr1: rx packet lost

2008-07-21 Thread Alexandre Guimaraes
Can one try to xplain this problem(kernel: vr1: rx packet lost) to me,
and how to resolve?

I´ve made several research about this, maybe a FreBSD problem, maybe
autosense net cards problem, maybe not!

Can one iluminate me with a conclusive solution?


Thanks Folks!

Alexandre

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [pfSense Support] kernel: vr1: rx packet lost

2008-07-21 Thread Michael Schuh
this could come from ugly via-rhine cards :-D
i had haved same Problem, after change my adapters to Intel
the errors gone away

2008/7/21 Alexandre Guimaraes [EMAIL PROTECTED]:

 Can one try to xplain this problem(kernel: vr1: rx packet lost) to me,
 and how to resolve?

 I´ve made several research about this, maybe a FreBSD problem, maybe
 autosense net cards problem, maybe not!

 Can one iluminate me with a conclusive solution?


 Thanks Folks!

 Alexandre

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




-- 
=== m i c h a e l - s c h u h . n e t ===
Michael Schuh
Postfach 10 21 52
66021 Saarbrücken
phone: 0681/8319664
mobil: 0177/9738644
@: m i c h a e l . s c h u h @ g m a i l . c o m

=== Ust-ID: DE251072318 ===


Re: [pfSense Support] DNS cache poisoning

2008-07-21 Thread Beat Siegenthaler

Chris Buechler wrote:

No, pf has randomized source ports on all NATed TCP and UDP traffic for 
8 years. I was surprised to find out that's the exception rather than 
the norm. Cisco, Checkpoint, amongst numerous others apparently do not 
randomize source ports on NATed traffic.




I am not enthusiastic about this:

Same Server behind pfSense and dd-wrt does differ sightly:
The server runs patched [EMAIL PROTECTED]


pfSense:

[EMAIL PROTECTED]:~] # dig +short porttest.dns-oarc.net TXT
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
IP is POOR: 26 queries in 4.7 seconds from 26 ports with std dev 8.47

dd-wrt:

[EMAIL PROTECTED]:~] # dig +short porttest.dns-oarc.net TXT
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
IP is GOOD: 26 queries in 4.6 seconds from 26 ports with std dev 17271.44

Source: https://www.dns-oarc.net/

Also the web-based test is very interesting:

pfsense:
source-port randomness=poor   (deviation 17)
transaction id randomness=great   (deviation 19030)

dd-wrt:
source-port randomness=great   (deviation 21110)
transaction id randomness=great   (deviation 17122)


Other Test @ www.doxpara.com :

Your name server, at x.y.z.y, may be safe, but the NAT/Firewall in front 
of it appears to be interfering with its port selection policy. The 
difference between largest port and smallest port was only 5.


Please talk to your firewall or gateway vendor -- all are working on 
patches, mitigations, and workarounds.

Requests seen for e85e29497dea.toorrr.com:
x.y.z.y:11970 TXID=47044
x.y.z.y:11971 TXID=62299
x.y.z.y:11972 TXID=65287
x.y.z.y:11973 TXID=13892
x.y.z.y:11975 TXID=50242


Not really a problem for me, but some may have ;-)


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: [pfSense Support] DNS cache poisoning

2008-07-21 Thread Tim Dickson
Tested using those tests, out of curiosity - and we passed with flying
colors.
Could it be your ISPs DNS that is bad? (that pfSense is relaying?) and not
pfSense directly?
-Tim

-Original Message-
From: Beat Siegenthaler [mailto:[EMAIL PROTECTED] 
Sent: Monday, July 21, 2008 1:11 PM
To: support@pfsense.com
Subject: Re: [pfSense Support] DNS cache poisoning

Chris Buechler wrote:

 No, pf has randomized source ports on all NATed TCP and UDP traffic for 
 8 years. I was surprised to find out that's the exception rather than 
 the norm. Cisco, Checkpoint, amongst numerous others apparently do not 
 randomize source ports on NATed traffic.
 

I am not enthusiastic about this:

Same Server behind pfSense and dd-wrt does differ sightly:
The server runs patched [EMAIL PROTECTED]


pfSense:

[EMAIL PROTECTED]:~] # dig +short porttest.dns-oarc.net TXT
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
IP is POOR: 26 queries in 4.7 seconds from 26 ports with std dev 8.47

dd-wrt:

[EMAIL PROTECTED]:~] # dig +short porttest.dns-oarc.net TXT
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
IP is GOOD: 26 queries in 4.6 seconds from 26 ports with std dev 17271.44

Source: https://www.dns-oarc.net/

Also the web-based test is very interesting:

pfsense:
source-port randomness=poor   (deviation 17)
transaction id randomness=great   (deviation 19030)

dd-wrt:
source-port randomness=great   (deviation 21110)
transaction id randomness=great   (deviation 17122)


Other Test @ www.doxpara.com :

Your name server, at x.y.z.y, may be safe, but the NAT/Firewall in front 
of it appears to be interfering with its port selection policy. The 
difference between largest port and smallest port was only 5.

Please talk to your firewall or gateway vendor -- all are working on 
patches, mitigations, and workarounds.
Requests seen for e85e29497dea.toorrr.com:
x.y.z.y:11970 TXID=47044
x.y.z.y:11971 TXID=62299
x.y.z.y:11972 TXID=65287
x.y.z.y:11973 TXID=13892
x.y.z.y:11975 TXID=50242


Not really a problem for me, but some may have ;-)


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [pfSense Support] DNS cache poisoning

2008-07-21 Thread Beat Siegenthaler

Tim Dickson wrote:


Could it be your ISPs DNS that is bad? (that pfSense is relaying?) and not
pfSense directly?
-Tim




Same Server behind pfSense and dd-wrt does differ sightly:
The server runs patched [EMAIL PROTECTED]



No ISP DNS, my own Server. Official DNS for my domains. In my DMZ.
Only difference during the test was a different firewall.

Maybe is Your DNS in Front of pfSense ?
 
Beat

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [pfSense Support] DNS cache poisoning

2008-07-21 Thread Chris Buechler
On Mon, Jul 21, 2008 at 4:10 PM, Beat Siegenthaler
[EMAIL PROTECTED] wrote:
 Chris Buechler wrote:

 No, pf has randomized source ports on all NATed TCP and UDP traffic for 8
 years. I was surprised to find out that's the exception rather than the
 norm. Cisco, Checkpoint, amongst numerous others apparently do not randomize
 source ports on NATed traffic.


 I am not enthusiastic about this:

 Same Server behind pfSense and dd-wrt does differ sightly:
 The server runs patched [EMAIL PROTECTED]


And it does recursive queries, does not rely on upstream servers? Are
you running with static port enabled? That's the only way your source
ports aren't going to be randomized, assuming the server is NATed and
not just firewalled. Static port disables the source port
randomization. This without question works as described.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [pfSense Support] DNS cache poisoning

2008-07-21 Thread Bill Marquette
On Mon, Jul 21, 2008 at 3:39 PM, Chris Buechler [EMAIL PROTECTED] wrote:
 On Mon, Jul 21, 2008 at 4:10 PM, Beat Siegenthaler
 [EMAIL PROTECTED] wrote:
 Chris Buechler wrote:

 No, pf has randomized source ports on all NATed TCP and UDP traffic for 8
 years. I was surprised to find out that's the exception rather than the
 norm. Cisco, Checkpoint, amongst numerous others apparently do not randomize
 source ports on NATed traffic.


 I am not enthusiastic about this:

 Same Server behind pfSense and dd-wrt does differ sightly:
 The server runs patched [EMAIL PROTECTED]


 And it does recursive queries, does not rely on upstream servers? Are
 you running with static port enabled? That's the only way your source
 ports aren't going to be randomized, assuming the server is NATed and
 not just firewalled. Static port disables the source port
 randomization. This without question works as described.

Unless the delay between queries given the same source port on the
querying machine is smaller than the UDP state timeout.  Nothing we
can do to solve this, it's an issue with the process doing the
querying.

--Bill

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [pfSense Support] DNS cache poisoning

2008-07-21 Thread Beat Siegenthaler

Chris Buechler wrote:



And it does recursive queries, does not rely on upstream servers? Are
you running with static port enabled? That's the only way your source
ports aren't going to be randomized, assuming the server is NATed and
not just firewalled. Static port disables the source port
randomization. This without question works as described.



Yes for internal hosts, I do recursive lookups.
Shure, wan incoming port tcp/udp 53 is NAT'ed to the Server in DMZ.

But also this is identical in both firewall setups dd-wrt/pfSense

And I think it is not really a big problem as long the transaction ID's 
are really good random.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[pfSense Support] PPTP and NAT

2008-07-21 Thread Ugo Bellavance

Hi,

	Is there a way to make it possible to have computers behind a Natting 
pfsense to connect to a PPTP server on the net?  More than one 
concurrent PPTP connection?


Regards,

Ugo


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[pfSense Support] Re: PPTP and NAT

2008-07-21 Thread Ugo Bellavance

Ugo Bellavance wrote:

Hi,

Is there a way to make it possible to have computers behind a 
Natting pfsense to connect to a PPTP server on the net?  More than one 
concurrent PPTP connection?


I forgot to add that we're using PPTP to connect remotely.  We could 
probably find another way to connect if we would need to make outgoing 
PPTP work.


Regards,

Ugo


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [pfSense Support] PPTP and NAT

2008-07-21 Thread Chris Buechler

Ugo Bellavance wrote:

Hi,

Is there a way to make it possible to have computers behind a 
Natting pfsense to connect to a PPTP server on the net?  More than one 
concurrent PPTP connection?


http://www.pfsense.org/index.php?option=com_contenttask=viewid=40Itemid=43
PPTP and GRE Limitation - The state tracking code in pf for the GRE 
protocol can only track a single session per public IP per external 
server. This means if you use PPTP VPN connections, only one internal 
machine can connect simultaneously to a PPTP server on the Internet. A 
thousand machines can connect simultaneously to a thousand different 
PPTP servers, but only one simultaneously to a single server. The only 
available work around is to use multiple public IPs on your firewall, 
one per client, or to use multiple public IPs on the external PPTP 
server. This is not a problem with other types of VPN connections. A 
solution for this is currently under development. 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [pfSense Support] DNS cache poisoning

2008-07-21 Thread Beat Siegenthaler

Beat Siegenthaler wrote:





And I think it is not really a big problem as long the transaction ID's 
are really good random.





Curiosity killed the Cat:

done a dump on pfSense at the dmz-side. It looks that the source ports 
from BIND are very good in random. But at the wan-side, the ports are 
just ascending more or less. What about the mentioned UDP timeout?
I try to check out another time what the openwrt, exactly X-WRT (it's 
not dd-wrt like mentioned before) guys do better in this case ...



 Number of samples: 29
   Unique ports: 29
   Range: 21929 - 21961
   Modified Standard Deviation: 9
   Bits of Randomness: 5
   Values Seen: 21929 21930 21931 21932 21933 21934 21935 21936 21937 
 21938 21939 21940 21941 21942 21943 21944 21945 21946 21947 21948

   21949 21950 21951 21952 21953 21954 21956 21960 21961

At the other side, the real good random values before NAT:

00:25:48.787921 4872 my_dns_server.9391  oarc_test.3.35.53:   47201%
00:25:48.979118 4872 my_dns_server.61156  oarc_test.3.36.53:   36685%
00:25:49.168621 4877 my_dns_server.44809  oarc_test.3.37.53:   6012%
00:25:49.357540 4878 my_dns_server.27958  oarc_test.3.38.53:   1136%
00:25:49.544582 4879 my_dns_server.56394  oarc_test.3.39.53:   1611%
00:25:49.731813 4880 my_dns_server.24383  oarc_test.3.40.53:   25202%
00:25:49.919190 4909 my_dns_server.60308  oarc_test.3.41.53:   58128%
00:25:50.108660 4924 my_dns_server.27970  oarc_test.3.42.53:   63983%
00:25:50.312579 4925 my_dns_server.16216  oarc_test.3.43.53:   257%
00:25:50.498615 4926 my_dns_server.34101  oarc_test.3.44.53:   54490%
00:25:50.689823 4928 my_dns_server.38677  oarc_test.3.45.53:   57967%
00:25:50.878837 4947 my_dns_server.39679  oarc_test.3.46.53:   32702%
00:25:51.068412 4966 my_dns_server.29164  oarc_test.3.47.53:   61296%
00:25:51.255607 4967 my_dns_server.13102  oarc_test.3.48.53:   58659%
00:25:51.471649 4968 my_dns_server.18020  oarc_test.3.49.53:   8577%
00:25:51.661415 4969 my_dns_server.31855  oarc_test.3.50.53:   63803%
00:25:51.850299 4982 my_dns_server.47298  oarc_test.3.51.53:   400%
00:25:52.039704 5007 my_dns_server.41360  oarc_test.3.52.53:   35624%
00:25:52.228943 5008 my_dns_server.18233  oarc_test.3.53.53:   24806%
00:25:52.418190 5009 my_dns_server.37245  oarc_test.3.54.53:   9403%
00:25:52.605281 5010 my_dns_server.49778  oarc_test.3.55.53:   24300%
00:25:52.796269 5017 my_dns_server.64789  oarc_test.3.56.53:   52018%
00:25:52.991502 5040 my_dns_server.63998  oarc_test.3.57.53:   7458%
00:25:53.181050 5049 my_dns_server.14257  oarc_test.3.58.53:   13284%
00:25:53.372107 5050 my_dns_server.8396  oarc_test.3.59.53:   24801%
00:25:53.561257 5053 my_dns_server.65268  oarc_test.3.59.53:   10654%
00:25:53.750866 5057 my_dns_server.44739  oarc_test.3.59.53:   20519%

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: [pfSense Support] Re: PPTP and NAT

2008-07-21 Thread Tim Dickson
Find another method, or set up an outside IP for every client.
-Tim

-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Ugo Bellavance
Sent: Monday, July 21, 2008 3:43 PM
To: support@pfsense.com
Subject: [pfSense Support] Re: PPTP and NAT

Ugo Bellavance wrote:
 Hi,
 
 Is there a way to make it possible to have computers behind a 
 Natting pfsense to connect to a PPTP server on the net?  More than one 
 concurrent PPTP connection?

I forgot to add that we're using PPTP to connect remotely.  We could 
probably find another way to connect if we would need to make outgoing 
PPTP work.

Regards,

Ugo


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [pfSense Support] DNS cache poisoning

2008-07-21 Thread Bill Marquette
On Mon, Jul 21, 2008 at 5:54 PM, Beat Siegenthaler
[EMAIL PROTECTED] wrote:

 done a dump on pfSense at the dmz-side. It looks that the source ports from
 BIND are very good in random. But at the wan-side, the ports are just
 ascending more or less. What about the mentioned UDP timeout?

Shouldn't make a difference if the source port is getting nat'd
sequentially.  That sounds a little odd to me, but I can check that
out when I get home and see if I can duplicate.  Can you send me
whatever test script you are using?  Thanks

--Bill

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [pfSense Support] DNS cache poisoning

2008-07-21 Thread Chris Buechler
On Mon, Jul 21, 2008 at 6:54 PM, Beat Siegenthaler
[EMAIL PROTECTED] wrote:
 Beat Siegenthaler wrote:




 And I think it is not really a big problem as long the transaction ID's
 are really good random.



 Curiosity killed the Cat:

 done a dump on pfSense at the dmz-side. It looks that the source ports from
 BIND are very good in random. But at the wan-side, the ports are just
 ascending more or less. What about the mentioned UDP timeout?
 I try to check out another time what the openwrt, exactly X-WRT (it's not
 dd-wrt like mentioned before) guys do better in this case ...


I just confirmed what I said previously, unless static port is enabled
the source port on DNS traffic (and all TCP and UDP traffic for that
matter) is rewritten to a randomly selected port. Description of this
behavior from OpenBSD developer Ryan McBride:
http://seclists.org/fulldisclosure/2008/Jul/0272.html

How is your outbound NAT configured?  Even static port won't rewrite
the source ports to something incremental, it just retains whatever
the source port is.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [pfSense Support] kernel: vr1: rx packet lost

2008-07-21 Thread Chris Buechler
On Mon, Jul 21, 2008 at 11:35 AM, Michael Schuh [EMAIL PROTECTED] wrote:
 this could come from ugly via-rhine cards :-D
 i had haved same Problem, after change my adapters to Intel
 the errors gone away


Yeah the vr driver in FreeBSD 6.2 isn't all that great. 6.3 and 7.0
have some improvements, so it's probably worthwhile to try 1.2.1.
There are a slew of vr fixes in FreeBSD RELENG_7 (what will become
7.1). Ermal attempted a back port to 7.0, I'm not sure if that was
completed or if it's included in any of our builds.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[pfSense Support] OpenVPN::Muitiple Clients

2008-07-21 Thread Diego A. Gomez
I have a OpenVPN Server (with PfSense)

I'm using pki-auth.

My problem is that I can't to connect 2 users at same time. When user
Aconnects itself,  user B is disconnected. Both users can't be
connected at same time (both users have diferents certs). What can be
the problem?

Thanks!

-- 
Diego.-

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [pfSense Support] DNS cache poisoning

2008-07-21 Thread Beat Siegenthaler

Bill Marquette wrote:


Shouldn't make a difference if the source port is getting nat'd
sequentially.  That sounds a little odd to me, but I can check that
out when I get home and see if I can duplicate.  Can you send me
whatever test script you are using?  Thanks


I use the Link: http://entropy.dns-oarc.net/test/
This generates a randomly choosen link like 
http://1ddade8a4f72fea465f51549.et.dns-oarc.net/
then the dns-oarc.net can check from which server the recursive query's 
came. Also quite good readable with lynx


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]