Re: Extending reported stats
Daniel Hartmeier wrote: If that works, reload your ruleset with $ pfctl -f /etc/pf.conf and verify $ pfctl -si If any of the above commands produces an error message, quote it. Maybe you added the "set loginterface" line and forgot to reload the ruleset? Daniel I'm so embarrased. I've reloaded the ruleset plenty of times, each time using the -Rf - seeing you put only -f clears it up. Thanks for the clue-in. DARREN
Nat Problem or misconfiguraton
Ok, I need some help. Here is my pf conf, stripped down so the nat works, and ifconfig out put also, can anyone figure out why it won't do nat on rl1, but will do it one rl0 Pf.conf: nat on rl0 inet from 192.168.0.7/32 to any -> rl0 nat on rl1 inet from 192.168.0.15/32 to any -> rl1 nat on rl1 inet from 192.168.0.4/32 to any -> rl1 nat on rl1 inet from 192.168.0.16/28 to any -> rl1 pass in all pass out all Ifconfig: rl0: flags=8843 mtu 1500 address: 00:50:fc:2a:17:5f media: Ethernet 100baseTX full-duplex status: active inet6 fe80::250:fcff:fe2a:175f%rl0 prefixlen 64 scopeid 0x1 inet 24.98.84.83 netmask 0xfe00 broadcast 255.255.255.255 (RL1 is listed with media options 10BaseT and autoselect) rl1: flags=8843 mtu 1500 address: 00:c0:26:7e:2c:3d media: Ethernet 10baseT status: active inet6 fe80::2c0:26ff:fe7e:2c3d%rl1 prefixlen 64 scopeid 0x2 inet 24.98.85.22 netmask 0xfe00 broadcast 255.255.255.255 rl1: flags=8843 mtu 1500 address: 00:c0:26:7e:2c:3d media: Ethernet autoselect (none) status: active inet6 fe80::2c0:26ff:fe7e:2c3d%rl1 prefixlen 64 scopeid 0x2 inet 24.98.85.22 netmask 0xfe00 broadcast 255.255.255.255 rl2: flags=8843 mtu 1500 address: 00:50:fc:3a:32:6d media: Ethernet 100baseTX full-duplex status: active inet 192.168.0.1 netmask 0xffe0 broadcast 192.168.0.0 inet6 fe80::250:fcff:fe3a:326d%rl2 prefixlen 64 scopeid 0x3 If rl0 & rl1 get dhcp assigned ips which are show, but rl1 won't nat, anyone got any ideas as to why the nat on rl0 works and not on rl1 Amir Seyavash Mesry [EMAIL PROTECTED] LSI Logic Corporation http://www.lsilogic.com/ Raid Support Test Technician 6145-D Northbelt Parkway Norcross, GA 30071 678-728-1211 NOTICE: This communication may contain privileged or other confidential information. If you are not the intended recipient, or believe that you have received this communication in error, please do not print, copy, retransmit, disseminate, or otherwise use the information. Also, please indicate to the sender that you have received this communication in error, and delete the copy you received. Thank you.
Re: Extending reported stats
On Fri, Jan 24, 2003 at 08:45:06AM -0700, Sancho2k.net Lists wrote: > >>First entry in /etc/pf.conf: > >>set loginterface fxp2 > > 3.2-RELEASE. I haven't had a real chance to update yet. Try $ echo "set loginterface fxp2" | pfctl -f - then $ pfctl -si If that works, reload your ruleset with $ pfctl -f /etc/pf.conf and verify $ pfctl -si If any of the above commands produces an error message, quote it. Maybe you added the "set loginterface" line and forgot to reload the ruleset? Daniel
Re: authpf and ~/.ssh/authorized_keys
On Fri, Jan 24, 2003 at 11:11:27AM -0500, Aaron Wade wrote: > I am trying to set up authpf users to use Public Key authentication in ssh. > I am trying it on a windows client at the present time, using ssh.com's > windows client. I create the key's and try to upload the pub key to the bsd > box and it just hangs. The users shell is /usr/sbin/authpf and I am sure > that makes all the difference. Is there a way to get authpf shell users to > use Public Key auth in ssh ? this is 3.2-stable. scp doesn't work if your shell is authpf, so you'll have to find another way to transfer the public key to the user's ~/.ssh/authorized_keys. But once the key is there, interactive login to authpf to get the rules updated will work just fine using public key authentication. Daniel
authpf and ~/.ssh/authorized_keys
Hi, I am trying to set up authpf users to use Public Key authentication in ssh. I am trying it on a windows client at the present time, using ssh.com's windows client. I create the key's and try to upload the pub key to the bsd box and it just hangs. The users shell is /usr/sbin/authpf and I am sure that makes all the difference. Is there a way to get authpf shell users to use Public Key auth in ssh ? this is 3.2-stable. Thanks ahead of time for any info. -Aaron
Re: Extending reported stats
Henning Brauer wrote: On Fri, Jan 24, 2003 at 02:33:22AM -0700, Sancho2k.net Lists wrote: Greetz, I want to figure out why pfctl isn't showing me statistics such as passed/blocked packets, packets per seconds, etc. In previous installations it has, but I must be missing something now. OpenBSD phantasm.sancho2k.net 3.2 GENERIC#25 i386 # pfctl -s info Status: Enabled for 7 days 05:21:47 Debug: None [the info you want would appear here with a loginterface set) State Table Total Rate First entry in /etc/pf.conf: set loginterface fxp2 I just verified the loginterface stuff works fine here... -current, -stable? i386, sparc64, vax, hppa? 3.2-RELEASE. I haven't had a real chance to update yet.
Re: pf+bridge+transparent proxy to local squid process
thanks to everyone for the replies! Well, the preference of bridge over routing/IP forwarding was just for simplification of deployment. And, keeping the squid process locally means cost savings for smaller office deployments. I've been building a similar (routing) solution using linux/netfilter/ZebOS devices (for larger installations); I'm not real keen on doing it this way any more. I tried the bridge+netfilter+squid approach and got weird behavior (yes, patched the Linux kernel - that's all I seem to do anymore :( ). Anyway, I agree that it would be preferable to not have that process local on the bridge (obviously removes some of the stealth), but that's the justification, just wanted to see if it was feasible. I will put another test system together and try it. Thanks again for all the help Cheers, -Mike - Original Message - From: "Daniel Hartmeier" <[EMAIL PROTECTED]> To: "Mike LaPane" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, January 24, 2003 6:11 AM Subject: Re: pf+bridge+transparent proxy to local squid process > Actually, the redirection itself will only work if the internal > interface has an IP address. > > A 'stealth' (IP-less) bridge functionally isolates its own userland from > any networks. No userland process can establish connections, as there is > no routing table. That's basically the point of such a setup, isolating > the firewall itself from the networks. Hence, the only thing really > working in such a setup is filtering with pf. > > Consequently, if you want to keep the bridge isolated, you have to > move the squid process to another host, and redirect the http > connections to there. It will probably require a dedicated interface and > some route-to/reply-to rules, too. > > The question is really why you don't want to assign addresses to the > bridge interfaces, and why you prefer the bridge setup over plain IP > forwarding. If it's to isolate the firewall userland from the networks, > well, that's exactly what you get :) > > Daniel
Re: pf+bridge+transparent proxy to local squid process
Daniel, Hmmm.. Thanks for the reply. I will definitely try it out and report back my findings. I would suggest then that with the strategic placing of a single IP address in the thread originator's bridge firewall the transparent squid proxy could possibly be made to work too. Hmmm, all cool things to try. BenR. On Fri, 2003-01-24 at 23:15, Daniel Hartmeier wrote: > On Fri, Jan 24, 2003 at 10:37:57PM +1100, Benjamin M.A. Robson wrote: > > > (Internet Cloud)--- > > | > > | > > [ fxp0 - No IP ] > > (Bridging Firewall)[ fxp2 - 10.0.0.1/24 ]---(Internal LAN) > > [ fxp1 - 2.2.2.2/24 ] > > | > > | > >( DMZ LAN ) > > > > The general behaviour of this was that the firewall acted as a bridge > > for packets traversing the network, but you could address the device > > using the internal interfaces IP address. > > > > When NAT was deployed on the external interface thus: > > map fxp0 10.0.0.0/24 to 2.2.2.2/32# approx representation of rule. > > > > ...and a default GW existed on the machine pointing to the upstream > > device... > > > > The packet behaviour from the 10/24 network was: > > 1. Packet from 10/24 arrives at interface fxp2 > > 2. Packet departs bridging firewall from fxp0 with source address > > mapped to the 2.2.2.2/32 address specified in the MAP rule. > > 3. Packet arrives at destination address. > > 4. Destination address replies to packet with packet arriving at fxp0 > > with a destination address of 2.2.2.2/32 (as one would expect per a > > normal NAT mapping. > > > > At this point a standard (non-bridging) firewall would pick the packet > > up, reverse map it, and push it to the destination device on the 10/24 > > network. > > > > However due to the bridge the packet would be picked up and -not- > > reverse translated. > > > > (In case you have your jaw on the floor this is a tested, working > > scenario. TCPDUMPS on independent machines on all network segments to > > watch the data flow) > > > > Do you have any thoughts on this and PF? > > Yes, this scenario should work with pf. The nat rule would look like this > > nat on fxp0 from 10.0.0.0/24 to any -> 2.2.2.2 > > This would apply only to packets leaving through fxp0. So an outgoing > connection from the internal LAN first arrives through fxp2 and gets > bridged to fxp0 (assuming the 10.0.0.x hosts use a default gateway on > the fxp0 side of the firewall). Before the packets leave fxp0, the nat > rule translates the source address to 2.2.2.2, so these packets go to > the gateway on the fxp0 side with a source address 2.2.2.2. This part is > mere bridging, as the internal host will use the destination MAC address > of the gateway on the fxp0 side, not any of the firewall's own MAC > addresses. > > Now, when the replies arrive on fxp0 (assuming the default gateway is > sending them to the firewall, because it associates 2.2.2.2 with fxp0's > MAC address), the destination address 2.2.2.2 gets translated back to the > appropriate 10.0.0.x address by pf. That part is guaranteed to work if > pf actually gets the replies. > > One important detail is that if those replies should have a destination MAC > address of fxp1 or fxp0 (depending on arp setup), the bridge detects that > the destination MAC address matches one of its own interfaces, and therefore > passes the packet to its own stack (after the reverse nat translation). > That's why you have to enable IP forwarding on the bridge, too. It's not > the bridge code that forwards the replies, but the IP forwarding code. > And that uses the routing table. If the internal interface has a 10.0.0.x > address (and the corresponding routing table entry), it will forward the > replies through fxp2. > > You'll have to test it, to know for sure. With bridging, you'll have to > consider not only IP addresses of packets, but also MAC addresses. The > bridge will itself forward packets based on MAC addresses, and pass > packets received for one of its own interfaces' MAC addresses to the > stack. Only when that happens, the routing table gets used. tcpdump > -e is very useful to debug these cases. > > Daniel -- Benjamin M.A. Robson <[EMAIL PROTECTED]> Achillean Pty. Ltd.
Re: pf+bridge+transparent proxy to local squid process
On Fri, Jan 24, 2003 at 10:37:57PM +1100, Benjamin M.A. Robson wrote: > (Internet Cloud)--- > | > | > [ fxp0 - No IP ] > (Bridging Firewall)[ fxp2 - 10.0.0.1/24 ]---(Internal LAN) > [ fxp1 - 2.2.2.2/24 ] > | > | > ( DMZ LAN ) > > The general behaviour of this was that the firewall acted as a bridge > for packets traversing the network, but you could address the device > using the internal interfaces IP address. > > When NAT was deployed on the external interface thus: > map fxp0 10.0.0.0/24 to 2.2.2.2/32# approx representation of rule. > > ...and a default GW existed on the machine pointing to the upstream > device... > > The packet behaviour from the 10/24 network was: > 1. Packet from 10/24 arrives at interface fxp2 > 2. Packet departs bridging firewall from fxp0 with source address > mapped to the 2.2.2.2/32 address specified in the MAP rule. > 3. Packet arrives at destination address. > 4. Destination address replies to packet with packet arriving at fxp0 > with a destination address of 2.2.2.2/32 (as one would expect per a > normal NAT mapping. > > At this point a standard (non-bridging) firewall would pick the packet > up, reverse map it, and push it to the destination device on the 10/24 > network. > > However due to the bridge the packet would be picked up and -not- > reverse translated. > > (In case you have your jaw on the floor this is a tested, working > scenario. TCPDUMPS on independent machines on all network segments to > watch the data flow) > > Do you have any thoughts on this and PF? Yes, this scenario should work with pf. The nat rule would look like this nat on fxp0 from 10.0.0.0/24 to any -> 2.2.2.2 This would apply only to packets leaving through fxp0. So an outgoing connection from the internal LAN first arrives through fxp2 and gets bridged to fxp0 (assuming the 10.0.0.x hosts use a default gateway on the fxp0 side of the firewall). Before the packets leave fxp0, the nat rule translates the source address to 2.2.2.2, so these packets go to the gateway on the fxp0 side with a source address 2.2.2.2. This part is mere bridging, as the internal host will use the destination MAC address of the gateway on the fxp0 side, not any of the firewall's own MAC addresses. Now, when the replies arrive on fxp0 (assuming the default gateway is sending them to the firewall, because it associates 2.2.2.2 with fxp0's MAC address), the destination address 2.2.2.2 gets translated back to the appropriate 10.0.0.x address by pf. That part is guaranteed to work if pf actually gets the replies. One important detail is that if those replies should have a destination MAC address of fxp1 or fxp0 (depending on arp setup), the bridge detects that the destination MAC address matches one of its own interfaces, and therefore passes the packet to its own stack (after the reverse nat translation). That's why you have to enable IP forwarding on the bridge, too. It's not the bridge code that forwards the replies, but the IP forwarding code. And that uses the routing table. If the internal interface has a 10.0.0.x address (and the corresponding routing table entry), it will forward the replies through fxp2. You'll have to test it, to know for sure. With bridging, you'll have to consider not only IP addresses of packets, but also MAC addresses. The bridge will itself forward packets based on MAC addresses, and pass packets received for one of its own interfaces' MAC addresses to the stack. Only when that happens, the routing table gets used. tcpdump -e is very useful to debug these cases. Daniel
Re: pf+bridge+transparent proxy to local squid process
Daniel, I don't have the hardware available to test this right now, but its on topic. Back when IPF was default for OBSD I did some experimenting with bridging and NAT with some limited success. The configuration I was using was thus... (Internet Cloud)--- | | [ fxp0 - No IP ] (Bridging Firewall)[ fxp2 - 10.0.0.1/24 ]---(Internal LAN) [ fxp1 - 2.2.2.2/24 ] | | ( DMZ LAN ) The general behaviour of this was that the firewall acted as a bridge for packets traversing the network, but you could address the device using the internal interfaces IP address. When NAT was deployed on the external interface thus: map fxp0 10.0.0.0/24 to 2.2.2.2/32# approx representation of rule. ...and a default GW existed on the machine pointing to the upstream device... The packet behaviour from the 10/24 network was: 1. Packet from 10/24 arrives at interface fxp2 2. Packet departs bridging firewall from fxp0 with source address mapped to the 2.2.2.2/32 address specified in the MAP rule. 3. Packet arrives at destination address. 4. Destination address replies to packet with packet arriving at fxp0 with a destination address of 2.2.2.2/32 (as one would expect per a normal NAT mapping. At this point a standard (non-bridging) firewall would pick the packet up, reverse map it, and push it to the destination device on the 10/24 network. However due to the bridge the packet would be picked up and -not- reverse translated. (In case you have your jaw on the floor this is a tested, working scenario. TCPDUMPS on independent machines on all network segments to watch the data flow) Do you have any thoughts on this and PF? If this could be made to work PF would be able to be used as a drop in firewall with a great reduction on routing modifications having to be made to existing LANs. Thoughts? Comments? Thanks, BenR. On Fri, 2003-01-24 at 22:11, Daniel Hartmeier wrote: > Actually, the redirection itself will only work if the internal > interface has an IP address. > > A 'stealth' (IP-less) bridge functionally isolates its own userland from > any networks. No userland process can establish connections, as there is > no routing table. That's basically the point of such a setup, isolating > the firewall itself from the networks. Hence, the only thing really > working in such a setup is filtering with pf. > > Consequently, if you want to keep the bridge isolated, you have to > move the squid process to another host, and redirect the http > connections to there. It will probably require a dedicated interface and > some route-to/reply-to rules, too. > > The question is really why you don't want to assign addresses to the > bridge interfaces, and why you prefer the bridge setup over plain IP > forwarding. If it's to isolate the firewall userland from the networks, > well, that's exactly what you get :) > > Daniel -- Benjamin M.A. Robson <[EMAIL PROTECTED]> Achillean Pty. Ltd.
Re: pf+bridge+transparent proxy to local squid process
Actually, the redirection itself will only work if the internal interface has an IP address. A 'stealth' (IP-less) bridge functionally isolates its own userland from any networks. No userland process can establish connections, as there is no routing table. That's basically the point of such a setup, isolating the firewall itself from the networks. Hence, the only thing really working in such a setup is filtering with pf. Consequently, if you want to keep the bridge isolated, you have to move the squid process to another host, and redirect the http connections to there. It will probably require a dedicated interface and some route-to/reply-to rules, too. The question is really why you don't want to assign addresses to the bridge interfaces, and why you prefer the bridge setup over plain IP forwarding. If it's to isolate the firewall userland from the networks, well, that's exactly what you get :) Daniel
Re: pf+bridge+transparent proxy to local squid process
On Thu, Jan 23, 2003 at 09:59:43PM -0500, Mike LaPane wrote: > I was just curious if anyone has tried to redirect like so: > rdr on $LAN_IF from $LAN_NET to any port 80 -> 127.0.0.1 port 3128 > while bridging? If so, does the bridge interface need to be IP'd? The redirection itself will work even if the interface doesn't have an address. But squid itself wants to open a tcp connection to the web server, and that only works if the host has an address and a default gateway. Daniel
Re: ipchains
On Fri, Jan 24, 2003 at 09:33:30AM +0100, Henning Brauer wrote: > On Thu, Jan 23, 2003 at 10:56:15AM -0800, Bryan Irvine wrote: > > Is there a converter out there for ipchains -> pf? > > it's called brain ;-) 8) Personally I always found ipchains/iptables invokes a certain crazyness to get a good ruleset. Would seem better to work from square one with the pf howto. Faster and the results should produce a better ruleset. -- Nicholas Lee - nj.lee at plumtree.co dot nz, somewhere on the fish Maui caught. gpg. 8072 4F86 EDCD 4FC1 18EF 5BDD 07B0 9597 6D58 D70Cicq. 1612865 Quixotic Eccentricity
Re: Extending reported stats
On Fri, Jan 24, 2003 at 02:33:22AM -0700, Sancho2k.net Lists wrote: > Greetz, > > I want to figure out why pfctl isn't showing me statistics such as > passed/blocked packets, packets per seconds, etc. In previous > installations it has, but I must be missing something now. > > > OpenBSD phantasm.sancho2k.net 3.2 GENERIC#25 i386 > # pfctl -s info > Status: Enabled for 7 days 05:21:47 Debug: None [the info you want would appear here with a loginterface set) > State Table Total Rate > First entry in /etc/pf.conf: > set loginterface fxp2 I just verified the loginterface stuff works fine here... -current, -stable? i386, sparc64, vax, hppa? -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Extending reported stats
Greetz, I want to figure out why pfctl isn't showing me statistics such as passed/blocked packets, packets per seconds, etc. In previous installations it has, but I must be missing something now. OpenBSD phantasm.sancho2k.net 3.2 GENERIC#25 i386 # pfctl -s info Status: Enabled for 7 days 05:21:47 Debug: None State Table Total Rate current entries2 searches 45749067.3/s inserts704110.1/s removals 704090.1/s Counters match 705880.1/s bad-offset 00.0/s fragment 00.0/s short 00.0/s normalize 00.0/s memory First entry in /etc/pf.conf: set loginterface fxp2 fxp2 is configured as part of bridge0: # ifconfig fxp2 fxp2: flags=8943 mtu 1500 address: 00:08:c7:ba:6f:95 media: Ethernet 100baseTX full-duplex status: active inet6 fe80::208:c7ff:feba:6f95%fxp2 prefixlen 64 scopeid 0x3 Suggestions? -- DARREN SPRUELL [EMAIL PROTECTED]
Re: ipchains
On Thu, Jan 23, 2003 at 10:56:15AM -0800, Bryan Irvine wrote: > Is there a converter out there for ipchains -> pf? it's called brain ;-) -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
