Re: Routing confusion?

onded! Julf On 14/01/13 18:36, Johan Helsingius wrote: > My firewall box has 3 net interfaces: > > > em0 (internal network): > inet 172.24.42.254 netmask 0xff00 broadcast 172.24.42.255 > em1 (internet): > inet 172.24.40.3 netmask 0xfc00 bro

Re: PF: route-to round-robin using single interface?

Just confirming that after fixing non-OpenBSD-related issues, round-robin works just fine even with only one interface. Julf On 14/01/13 17:53, Johan Helsingius wrote: > Hi! > > I have a small network, connected by 2 ADSL connections, and > want to load-share the conn

Re: Routing confusion?

Peter, > :em0 (internal network): > :inet 172.24.42.254 netmask 0xff00 broadcast 172.24.42.255 > :em2 (wifi sandbox): > :inet 172.24.42.223 netmask 0xffc0 broadcast 172.24.42.255 > : > > You can't do that. What specific reason is there that that won't work? Isn't it just

Re: Routing confusion?

Aaron, > Another note, it would be prudent to put your ADSL modems onto each of > their own networks, or better yet (and if you can), run them in > bridge/modem mode and use pppoe(4) to fire up the connection. That > way the firewall is on the outside of the network. I did that for a long time,

Routing confusion?

My firewall box has 3 net interfaces: em0 (internal network): inet 172.24.42.254 netmask 0xff00 broadcast 172.24.42.255 em1 (internet): inet 172.24.40.3 netmask 0xfc00 broadcast 172.24.43.255 em2 (wifi sandbox): inet 172.24.42.223 netmask 0xffc0 broadcast 172.2

PF: route-to round-robin using single interface?

Hi! I have a small network, connected by 2 ADSL connections, and want to load-share the connections. All examples of route-to round-robin that I have seen have used 2 separate interfaces, but as both my ADSL modems are on the same "no-mans-land" network, I have been (so far unsuccessfully) trying

Re: I want copy pf.conf from FreeBSD 8.2 to OpenBSD 5 and use it

> Never thought I would see confucionism on misc@ "Confucius say too much.  recent Chinese proverb" (from fortune(6)) Julf

Re: more pf strangeness

An update... > Feb 16 16:44:38.484106 rule def/(short) [uid 0, pid 0] pass > out on xl2: fie.fue.com.5 > 172.24.44.89.0: [udp sum ok] > udp 16 (DF) (ttl 43, id 0, len 44, bad cksum a33e! differs by 100) > > So for some reason I see a misformed, short packet going *out* > of the firewall, bu

more pf strangeness

Hi again... I am seeing some strange stuff in my pf log. My situation: - OpenBSD firewall, with 3 interfaces (OpenBSD 4.8 GENERIC.RAID#0 i386) - rl0, with address 82.171.180.235, connecting to ADSL modem - xl0, with address 172.24.42.2, connecting to my internal network, from where

Re: meaning of pflog / tcpdump output

> The "short" reason code indicates that the packet was truncated or too short > and therefore was missing information required to make a packet filtering > decision. This could be, for example, a packet that only contained the first > few bytes of an IP datagram (or a header that states that it

Re: meaning of pflog / tcpdump output

Matteo, > all you need is at > > http://www.openbsd.org/cgi-bin/man.cgi?query=tcpdump&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html Thanks, but as I wrote: >> I am getting a fair bit of log lines that are shown as >> "rule def/(short)", and I can't find anything explaining >

meaning of pflog / tcpdump output

Hi! Another really stupid question - is the full output format of tcpdump when dumping the pflog0 device documented somewhere? I am getting a fair bit of log lines that are shown as "rule def/(short)", and I can't find anything explaining the meaning of things like "(short)" - the tcpdump man page

Re: Donations

> This is my source: > That states "This quotation is at least partly spurious" :) Julf

Re: Donations

Jasper, > Imho this Thomas Jefferson quote is better suited for the subject. ;-) http://www.snopes.com/quotes/jefferson/banks.asp Julf

pf logs - no packet header data (4.8)

Hi! Setting up a firewall with 4.8, I was rather surprised to see that I don get any logged info from the blocked packets (beyond the fact that they were blocked). I assume I am missing some silly little thing... # tcpdump -n -e -ttt -i pflog0 tcpdump: listening on pflog0, link-type PFLOG Nov 14