Re: Internal IP Address Detection Through NAT
Hello, Thanks everyone for your comments. I should have guessed that it would be a Java script or something. I disabled Java in Internet Explorer and the site I was talking about was not able to get the internal ip address anymore. Thanks again. -- Best regards, William mailto:[EMAIL PROTECTED]
Internal IP Address Detection Through NAT
Hello, I know this has been discussed before, but I looked through the list and could not find what I was looking for. I was browsing a security audit website and not only did it show the external ip address given to me by my isp (this is to be expected), but it also showed the internal ip address of the machine I connected to the site with as well. I cannot recall if this is to be expected or not, but the site I was looking at did not think so. The machine I connected with runs Windows 2000 Pro. Feel free to point me to any discussions on this. -- Best regards, William mailto:[EMAIL PROTECTED]
RE: disabling altq in the new pf/altq merge
> what was it? It is rather embarrassing actually. I run BIND internally for caching and name resolution and forgot to reenable it when I upgraded /etc/rc.conf. > think about testing that altq stuff I just might now. Thanks for the diff. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.422 / Virus Database: 237 - Release Date: 11/20/2002
RE: disabling altq in the new pf/altq merge
My mistake. I just figured out the problem. Thank You. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.422 / Virus Database: 237 - Release Date: 11/20/2002
disabling altq in the new pf/altq merge
I read the pf.conf man page and did not see anything about disabling altq now that is merged with pf. I don't really have a need to have it running and for some reason, my gateway is no longer passing any traffic after upgrading to -current today. Do I have to add altq rules for traffic to passed now? Thanks for any help. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.422 / Virus Database: 237 - Release Date: 11/20/2002
RE: Curious about interactions with pf and some file sharing programs
> I don't think you ever need to pass any traffic at the border gateway just > to drop it at the final destination, you can just as well drop it at the > > border. Excellent point. I have taken care of it as suggested. Thanks again. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.401 / Virus Database: 226 - Release Date: 10/9/2002
Re: Curious about interactions with pf and some file sharing programs
> Yes, the 'keep state' option in that rules allows replies to your > outgoing UDP packets. I figured that was the case, but I just wanted to verify. I definitely want to continue using "keep state" on outgoing UDP traffic so I decided to install a software firewall on the particular Windows machine that I use Kazaa on and block the incoming UDP packets there. Thanks for the reply. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.401 / Virus Database: 226 - Release Date: 10/9/2002
Curious about interactions with pf and some file sharing programs
I have noticed that when I use some p2p file sharing programs, Kazaa more specifically, that some udp traffic is able to slip back through my OpenBSD box running nat/pf. I was curious if this is because I use a "pass out on $Ext proto udp all keep state" rule, and traffic initiated by me is allowed to return, or is there is some other reason? I don't allow any incoming traffic other than ssh. Thanks for any info. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.401 / Virus Database: 226 - Release Date: 10/9/2002
Curious about PF and some P2P Programs
I have noticed that incoming UDP traffic from programs like Kazaa are able to slip right through PF. I pass all outgoing traffic on the firewall (TCP/UDP) and block most everything coming in except for a couple of services (none of which use UDP). Am I correct in thinking that the reason this traffic is able to slip through is because I use keep state on all my outgoing UDP traffic and in order to stop this from happening I would need to create a separate rule for outgoing Kazaa UDP traffic without keeping state? Or, am I completely off base and there is another reason for it? --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.389 / Virus Database: 220 - Release Date: 9/16/2002
RE: NAT problems
Could you post your entire nat.conf. The :18 means that the syntax error is on line 18 of the file. You probably knew that, but I would like to see it.
RE: NAT problems
Try this: ext_if = "dc0" # External Interface int_if = "dc1" # Internal Interface IntNet = "192.168.1.0/24" # Internal Network Put spaces between the equal signs just in case. Leave the brackets out around the interfaces. Use $ext_if, $int_if, and $IntNet for filter rules, but try not using them on nat rules like this: nat on dc0 from 192.168.1.0/24 to any -> dc0
