Re: Fwd: Re: pf stopped working i think... WORKS. specifying loopback device lo no longer works in pf.conf though
b h wrote: pass quick on lo all used to work before the hackathon. pass quick on lo0 all I'm not sure if I just missed it or if you didn't mention it, but I didn't realize you were running -current. There's lots of work ongoing in -current on interface groups. Henning is doing some neat stuff; it's going to be really cool when he's finished. Until quite recently, the interface family group didn't exist. You're probably running a snapshot where that's the case. You should be good to go with a recent -current. .joel
Re: viewing packet data with tcpdump?
tcpdump is pretty much just for inspecting the headers of packets, to capture data and entire sessions, snort would be a good tool to use. It can be ran on the command line in a way similar to tcpdump and dump complete data to a pcap file for later inspection with tools such as ethereal. Generally it isn't recommended to use ethereal for sniffing/collecting data due to possible security risks that may pose. On 6/7/05, Rick Barter [EMAIL PROTECTED] wrote: I use tcpdump to trouble-shoot my firewall, set up my rules, etc. I found the -x option which dumps the packet in hex. Can I view the packet data with tcpdump or do I need to install Ethereal or something? Any help is appreciated. rvb
Re: limitation of PF while forwarding ports --help
Siju George [EMAIL PROTECTED] writes: Is PF not capable of letting two users ( with two differrent computers with 2 differrent IP from the RFC1918 range ) in the LAN to connect to the Same Windows 2003 remote desktop server on the Internet and work on it simultaneously??? The only workaround to connect to Windows Remote Desktop Server through PF I know of now is to use an rdr rule to do port forwarding something like. code: rdr pass on $ext_if inet proto tcp from $Windows_RDServer to any port 3389 - $WRD_client1 port 3389 I may be revealing the true abysses of my ignorance here, but would not a reasonable NAT combined with something like pass inet proto tcp from $localnet to $Windows_RDServer port 3389 keep state 'just work'? Does the server need to start connections which are not taken care of by the state information back to the clients? -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ First, we kill all the spammers The Usenet Bard, Twice-forwarded tales
Re: limitation of PF while forwarding ports --help
On 6/8/05, Peter N. M. Hansteen [EMAIL PROTECTED] wrote: Siju George [EMAIL PROTECTED] writes: Is PF not capable of letting two users ( with two differrent computers with 2 differrent IP from the RFC1918 range ) in the LAN to connect to the Same Windows 2003 remote desktop server on the Internet and work on it simultaneously??? The only workaround to connect to Windows Remote Desktop Server through PF I know of now is to use an rdr rule to do port forwarding something like. code: rdr pass on $ext_if inet proto tcp from $Windows_RDServer to any port 3389 - $WRD_client1 port 3389 I may be revealing the true abysses of my ignorance here, but would not a reasonable NAT combined with something like pass inet proto tcp from $localnet to $Windows_RDServer port 3389 keep state 'just work'? Does the server need to start connections which are not taken care of by the state information back to the clients? Thankyou so much Peter and Daniel for the reply :-) There has been some misunderstanding from my part that the RDserver calls back to the port 3389 of the client too. I just got confused by the wordings used in the website. it is clear now and the problem aplies to neteeting and things only not connecting to Windows RD. Sorry for the trouble :-( kind regards Siju
Re: viewing packet data with tcpdump?
craSH wrote: tcpdump is pretty much just for inspecting the headers of packets, to capture data and entire sessions, snort would be a good tool to use. It can be ran on the command line in a way similar to tcpdump and dump complete data to a pcap file for later inspection with tools such as ethereal. Generally it isn't recommended to use ethereal for sniffing/collecting data due to possible security risks that may pose. On 6/7/05, Rick Barter [EMAIL PROTECTED] wrote: I use tcpdump to trouble-shoot my firewall, set up my rules, etc. I found the -x option which dumps the packet in hex. Can I view the packet data with tcpdump or do I need to install Ethereal or something? Any help is appreciated. rvb You might also check into /usr/ports/net/tcpshow. It gives you the 'snoop' type output. cheers
Re: viewing packet data with tcpdump?
On Tue, 2005-06-07 at 22:05:33 -0700, craSH proclaimed... tcpdump is pretty much just for inspecting the headers of packets, to capture data and entire sessions, snort would be a good tool to use. Wow, quit spreading bad information. tcpdump(8) is to capture packets, in full or part. Those captures can then be dissected with tools. The original poster may want to look at tcpshow or ngrep.
Re: Fwd: Re: pf stopped working i think... WORKS. specifying loopback device lo no longer works in pf.conf though
* j knight [EMAIL PROTECTED] [2005-06-08 18:01]: b h wrote: pass quick on lo all used to work before the hackathon. pass quick on lo0 all I'm not sure if I just missed it or if you didn't mention it, but I didn't realize you were running -current. There's lots of work ongoing in -current on interface groups. Henning is doing some neat stuff; it's going to be really cool when he's finished. Until quite recently, the interface family group didn't exist. You're probably running a snapshot where that's the case. You should be good to go with a recent -current. atually, the interface family groups have been there for a long time... more or less. they are now there for cloned interfaces like tun, ppp, vlan and the like, but not for hardware interfaces like sk, em etc where they just don't make sense. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de OpenBSD-based Webhosting, Mail Services, Managed Servers, ...
Re: viewing packet data with tcpdump?
I gotta ask what your reasoning is for not running Ethereal as far as it being a security risk. for starters, it was removed from the openbsd ports tree for being so insecure. it has had a number of major security problems in its recent past: http://www.ethereal.com/appnotes/
Re: viewing packet data with tcpdump?
On Wed, 2005-06-08 at 14:29:13 -0400, Amir S Mesry proclaimed... I gotta ask what your reasoning is for not running Ethereal as far as it being a security risk. There are problems with some of the decodes in past ethereal releases that were considered security vulnerabilities. For this reason, it was taken of out the ports tree. Any trivial google searching should provide you more information.
Re: viewing packet data with tcpdump?
I gotta ask what your reasoning is for not running Ethereal as far as it being a security risk. for starters, it was removed from the openbsd ports tree for being so insecure. it has had a number of major security problems in its recent past: http://www.ethereal.com/appnotes/
Re: viewing packet data with tcpdump?
eric wrote: On Tue, 2005-06-07 at 22:05:33 -0700, craSH proclaimed... tcpdump is pretty much just for inspecting the headers of packets, to capture data and entire sessions, snort would be a good tool to use. Wow, quit spreading bad information. tcpdump(8) is to capture packets, in full or part. Those captures can then be dissected with tools. The original poster may want to look at tcpshow or ngrep. Wow. Thanks. tcpshow is exactly what I was looking for. I just compiled it and used it to read one of the emails I just sent. I feel so naked and vulnerable now! Holy crap! I need to install PHP ...RFN!!! rvb
