Hi,
I have a few questions about the inner workings of netfilter
(a graphical layout of my network setup @
https://aequorin.homeunix.net:62389/local/media/network-graph.png)
1) These are the syslog entries for some simple connection tests.
Shorewall/netfilter has been set to record all stateful connections
SSH is recognized as phys(eth0) -> $FW traffic. This is because PHYSIN
is set.
Why is this? Why is SSH not lan(br0) -> $FW ?
You mentioned that unless the physdev flag is set, shorewall only cares
about lan(br0) <-> $FW
Why does PHYSIN get set for SSH ?
ping(server->lan)
Sep 14 23:42:45 veridian kernel: [618269.196281]
Shorewall:fw2lan:ACCEPT:INOUT=br0 SRC=192.168.1.6 DST=192.168.1.255 LEN=185
TOS=0x00 PREC=0x00 TTL=64
ID=0 DF PROTO=UDP SPT=631 DPT=631 LEN=165
ssh
Sep 14 23:45:15 veridian kernel: [618418.797081]
Shorewall:phys2fw:ACCEPT:IN=br0 OUT= PHYSIN=eth0
MAC=00:01:29:f5:f0:26:00:18:01:5b:a8:72:08:00 SRC=207.172.176.168 DST192.168.1.6
LEN=52 TOS=0x00 PREC=0x00 TTL=253 ID=32555 DF PROTO=TCP
SPT=45664 DPT=48232 WINDOW=8192 RES=0x00 SYN URGP=0
openvpn (3 types)
Sep 14 23:46:54 veridian kernel: [618517.248260]
Shorewall:vpn2phys:ACCEPT:IN=br0 OUT=br0 PHYSIN=tap0 PHYSOUT=eth0
SRC192.168.1.225 DST=192.168.1.255 LEN=96 TOS=0x00 PREC=0x00 TTL=128 ID=33
PROTO=UDP SPT=137 DPT=137 LEN=76
Sep 14 23:46:53 veridian kernel: [618516.835299]
Shorewall:fw2lan:ACCEPT:INOUT=br0 SRC=192.168.1.6 DST=192.168.1.255 LEN=185
TOS=0x00 PREC=0x00 TTL=64
ID=0 DF PROTO=UDP SPT=631 DPT=631 LEN=165
Sep 14 23:46:59 veridian kernel: [618522.262747]
Shorewall:phys2vpn:ACCEPT:IN=br0 OUT=br0 PHYSIN=eth0 PHYSOUT=tap0 SRC192.168.1.1
DST=239.255.255.250 LEN=429 TOS=0x00 PREC=0x00 TTL=4 ID=0 DF
PROTO=UDP SPT=1900 DPT=1900 LEN=409
ping(vpn client->server)
Sep 14 23:50:50 veridian kernel: [618753.216549]
Shorewall:lan2fw:REJECT:IN=br0 OUT= PHYSIN=tap0
MAC=00:01:29:f5:f0:26:00:ff:09:52:47:a0:08:00 SRC=192.168.1.225 DST192.168.1.6
LEN=60 TOS=0x00 PREC=0x00 TTL=128 ID=101 PROTO=ICMP TYPE=8
CODE=0 ID=1 SEQ=3
ping(vpn server->client)
Sep 14 23:52:34 veridian kernel: [618857.273217]
Shorewall:fw2lan:ACCEPT:INOUT=br0 SRC=192.168.1.6 DST=192.168.1.255 LEN=185
TOS=0x00 PREC=0x00 TTL=64
ID=0 DF PROTO=UDP SPT=631 DPT=631 LEN=165
ping(vpn client->lan)
Sep 14 23:55:39 veridian kernel: [619041.782974]
Shorewall:vpn2phys:ACCEPT:IN=br0 OUT=br0 PHYSIN=tap0 PHYSOUT=eth0
SRC192.168.1.225 DST=192.168.1.2 LEN=60 TOS=0x00 PREC=0x00 TTL=128 ID=123
PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=6
2) How do the PHYSIN/PHYSOUT ''flags'' get set? What criteria
has to be
met. Does the bridge interface set these flags ?
3) Is the following a correct generalization of traffic pasing through
netfilter:
(normal, no vpn)
incoming: phys(eth0) -> $FW
outgoing: $FW -> lan(br)
(vpn)
outgoing: phys(eth0) -> vpn(tap0)
---then---
$FW -> lan(br0)
incoming: vpn(tap0) -> phys(eth0)
---or-----
lan(br0) -> $FW
so outgoing vpn traffic has to pass through netfilter twice, first
phys(eth0) -> vpn(tap0), then $FW -> lan(br0)
while incoming vpn traffic passes through netfilter once, but goes
one of two possible ''routes'' depending on the destination
((vpn client ->
lan) vs (vpn client -> vpn server))
4) The shorewall docs mention that the lan(br0) zone exists b/c it is not
possible to do $FW->vpn(tap0) or $FW->phys(eth0)
Is this because netfilter in kernels >=2.6.20 cannot recognize
$FW->vpn(tap0) or $FW->phys(eth0) ?
... because I havent seens any traffic that would match $FW->vpn(tap0)
or $FW->phys(eth0).
much appreciated,
orbisvicis
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer''s
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
Yclept Nemo wrote:> Hi, > > I have a few questions about the inner workings of netfilter > (a graphical layout of my network setup @ > https://aequorin.homeunix.net:62389/local/media/network-graph.png) >Rather than answer each of your first three individual questions, I''m going to try to explain to you how it works. Here is a diagram of what is going on: _____________ ____________ | | | | | VPN Clients | | LAN Hosts | |_____________| |____________| | | | | ---------------- ----------------- | eth0 | | tap0 | |----------------------------------------------------| | br0 | |----------------------------------------------------| | | | $FW | |____________________________________________________| So: 1) Any packet from a VPN client will have PHYSIN=eth0. 2) Any packet from a LAN host will have PHYSIN=tap0. 3) Any packet to the firewall will have PHYSOUT= because the connection does not go out either of the ''physical'' (layer 2) interfaces (bridge ports). 4) All traffic must pass through the bridge; traffic never passes directly from one bridge port to another. The bridge is always the IN= interface for traffic from the VPN clients and LAN hosts and it is always the OUT= interface for traffic to those clients and hosts.> > 4) The shorewall docs mention that the lan(br0) zone exists b/c it is > not possible to do $FW->vpn(tap0) or $FW->phys(eth0) > > Is this because netfilter in kernels >=2.6.20 cannot recognize > $FW->vpn(tap0) or $FW->phys(eth0) ? > ... because I havent seens any traffic that would match > $FW->vpn(tap0) or $FW->phys(eth0).That is correct -- In order to be associated with an output physical device (PHYSOUT=), a packet must have entered the bridge through a physical device (port). It cannot have been routed from another IPv4 interface (one with an IPV4 address) and it cannot have originated on the firewall itself. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Tom Eastep
2008-Sep-17 15:44 UTC
Re: netfilter + vpn + how/why + etc... -- Corrected Diagram
I had the port labels reversed in the first version. -Tom Yclept Nemo wrote:> Hi, > > I have a few questions about the inner workings of netfilter > (a graphical layout of my network setup @ > https://aequorin.homeunix.net:62389/local/media/network-graph.png) >Rather than answer each of your first three individual questions, I''m going to try to explain to you how it works. Here is a diagram of what is going on: _____________ ____________ | | | | | VPN Clients | | LAN Hosts | |_____________| |____________| | | | | ---------------- ----------------- | tap0 | | eth0 | |----------------------------------------------------| | br0 | |----------------------------------------------------| | | | $FW | |____________________________________________________| So: 1) Any packet from a VPN client will have PHYSIN=eth0. 2) Any packet from a LAN host will have PHYSIN=tap0. 3) Any packet to the firewall will have PHYSOUT= because the connection does not go out either of the ''physical'' (layer 2) interfaces (bridge ports). 4) All traffic must pass through the bridge; traffic never passes directly from one bridge port to another. The bridge is always the INinterface for traffic from the VPN clients and LAN hosts and it is always the OUT= interface for traffic to those clients and hosts.> > 4) The shorewall docs mention that the lan(br0) zone exists b/c it is > not possible to do $FW->vpn(tap0) or $FW->phys(eth0) > > Is this because netfilter in kernels >=2.6.20 cannot recognize > $FW->vpn(tap0) or $FW->phys(eth0) ? > ... because I havent seens any traffic that would match > $FW->vpn(tap0) or $FW->phys(eth0).That is correct -- In order to be associated with an output physical device (PHYSOUT=), a packet must have entered the bridge through a physical device (port). It cannot have been routed from another IPv4 interface (one with an IPV4 address) and it cannot have originated on the firewall itself. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Tom Eastep
2008-Sep-17 15:46 UTC
Re: netfilter + vpn + how/why + etc... -- Corrected Diagram and Text
Groan -- And I had the text labels reversed in the second version. I shouldn''t answer email before having coffee. -Tom Yclept Nemo wrote:> Hi, > > I have a few questions about the inner workings of netfilter > (a graphical layout of my network setup @ > https://aequorin.homeunix.net:62389/local/media/network-graph.png) >Rather than answer each of your first three individual questions, I''m going to try to explain to you how it works. Here is a diagram of what is going on: _____________ ____________ | | | | | VPN Clients | | LAN Hosts | |_____________| |____________| | | | | ---------------- ----------------- | tap0 | | eth0 | |----------------------------------------------------| | br0 | |----------------------------------------------------| | | | $FW | |____________________________________________________| So: 1) Any packet from a VPN client will have PHYSIN=tap0. 2) Any packet from a LAN host will have PHYSIN=eth0. 3) Any packet to the firewall will have PHYSOUT= because the connection does not go out either of the ''physical'' (layer 2) interfaces (bridge ports). 4) All traffic must pass through the bridge; traffic never passes directly from one bridge port to another. The bridge is always the INinterface for traffic from the VPN clients and LAN hosts and it is always the OUT= interface for traffic to those clients and hosts.> > 4) The shorewall docs mention that the lan(br0) zone exists b/c it is > not possible to do $FW->vpn(tap0) or $FW->phys(eth0) > > Is this because netfilter in kernels >=2.6.20 cannot recognize > $FW->vpn(tap0) or $FW->phys(eth0) ? > ... because I havent seens any traffic that would match > $FW->vpn(tap0) or $FW->phys(eth0).That is correct -- In order to be associated with an output physical device (PHYSOUT=), a packet must have entered the bridge through a physical device (port). It cannot have been routed from another IPv4 interface (one with an IPV4 address) and it cannot have originated on the firewall itself. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Thanks for the info, however I could use some clarification (the nitty-gritty details) on my 3rd question. (normal, no vpn) incoming: phys(eth0) -> $FW outgoing: $FW -> lan(br) 1) outgoing $FW -> lan(br0) will in actuality always be $FW -> phys(eth0) (?) The shorewall docs also mention that all vpn traffic will pass through netfilter twice. I see this happening on outgoing vpn traffic: (vpn) outgoing: phys(eth0) -> vpn(tap0) ---then--- $FW -> lan(br0) This first entry completes the chain from eth0 -> lan(br0) -> vpn(tap0) -> server Then the second follows from server($FW) -> lan(br0), which will output phys(eth0) Blocking either of these chains will make it impossible for a vpn packet to leave the server. 3) Is this [the above] correct (?) 2) similarly, the $FW -> lan(br0) will in actuality always be $FW -> phys(eth0) ? i.e. the outgoing bridge port will never be tap0. However, incoming vpn traffic seems to travel over only one of two possible routes: (vpn) incoming: vpn(tap0) -> phys(eth0) ---or----- lan(br0) -> $FW The first route is solely for (vpn client -> lan) communication the second route is only for (vpn client -> vpn server) communications (see what I recorded in the syslog) Blocking either of these routes only blocks the respective communication chain. 4) why doesn''t incoming traffic travel through netfilter twice ? Similarly, why doesn''t all incoming traffic have to cross the $FW zone just like outgoing vpn traffic has to. I''d expect some symmetricity between the incoming/outgoing vpn connections 5) In a similar vein, ping(vpn client->server) travels from lan(br0) -> $FW despite the PHYSIN=tap0 Doesn''t this contradict what you said in your previous response? Shouldn''t ping(vpn client->server) be vpn(tap0) -> $FW because of PHYSIN? Take your time; have your coffee ; ) thanks, orbisvicis ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Yclept Nemo wrote:> Thanks for the info, however I could use some clarification (the > nitty-gritty details) on my 3rd question.You''ve gotten everything from me that you are going to get. -Tom -- Tom Eastep \ The ultimate result of shielding men from the effects of folly \ is to fill the world with fools -- Herbert Spencer Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Tom Eastep wrote:> Yclept Nemo wrote: >> Thanks for the info, however I could use some clarification (the >> nitty-gritty details) on my 3rd question. > > You''ve gotten everything from me that you are going to get.So as not to propagate bad English grammar, let me rephrase that: You have received all of the help from me that you are going to receive. On IRC, you have admitted that you are not a serious Shorewall user and that you are simply playing with Shorewall as a learning tool. Given that is the case, I don''t have the time or the interest to act as your Netfilter/bridge tutor. Please consider that there are thousands of Shorewall users and only one of me; and my full-time job has nothing to do with Shorewall. In fact, I have never had a job that had anything to do with networking in any form. I am always willing to help users who have Shorewall problems but I''m not available to act as a Linux networking tutor for you, no matter how eager you are. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Tom Eastep wrote:> I am always willing to help users who have Shorewall problems but I''m > not available to act as a Linux networking tutor for you, no matter how > eager you are.I will give you one piece of advice, however. Set IMPLICIT_CONTINUE=No in shorewall.conf; you will find that your log messages will make more sense. And if you ask any more questions, please include the actual log messages and configuration data that you used to draw your conclusions; Otherwise, we can''t take your assertions seriously. For example, you said that you see two output messages on $FW->VPN traffic -- I suspect that one of them was a DNS query which is why you didn''t see a similar message on VPN->$FW. Because if you are logging using policies, you should only see one $FW->... message generated by openvpn; when you first established the VPN connection. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
hey, that helped a lot, I set IMPLICIT_CONTINUE=No and then ran the connection tests again... voila, everything made more sense I now log vpn(tap0) -> $FW instead of the nonsensical lan(br0) -> $FW Furthermore, the outgoing vpn paths now are actually separate: $FW -> lan(br0) only for: (vpn server->vpn client) ----or---- phys(eth0) -> vpn(tap0) only for: (lan->vpn client) Blocking one no longer blocks the other. I have never recorded $FW -> vpn(tap0). I do get $FW -> lan(br0), but that is outgoing, i.e. in actuality $FW -> phys(eth0) Nonetheless its good to know that DNS queries are only one-way. I also find it interesting that network broadcasts travel on both possible bridge-port pathways: phys(eth0) -> $FW phy(eth0) -> vpn(tap0) Out of curiosity, is it normal for a windows computer to be continuously sending out UDP broadcasts, of this form ? MAC=ff:ff:ff:ff:ff:ff:00:1d:7d:a4:2f:7a:08:00 SRC=192.168.1.2 DST=192.168.1.255 LEN=99 TOS=0x00 PREC=0x00 TTL=128 ID=13583 PROTO=UDP SPT=62994 DPT=5353 LEN=79 Is it DNS or some-such ? thanks for your guidance, orbisvicis Also, just for the record, I actually am serious about using Shorewall. It is just that even though Shorewall/netfilter *does* run correctly, I want to know why and how. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Yclept Nemo wrote:> Out of curiosity, is it normal for a windows computer to be > continuously sending out UDP broadcasts, of this form ? > MAC=ff:ff:ff:ff:ff:ff:00:1d:7d:a4:2f:7a:08:00 SRC=192.168.1.2 > DST=192.168.1.255 LEN=99 TOS=0x00 PREC=0x00 TTL=128 ID=13583 PROTO=UDP > SPT=62994 DPT=5353 LEN=79 > Is it DNS or some-such ? > > thanks for your guidance, > orbisvicisHi, Just a LITTLE bit of searching led me to <http://www.multicastdns.org/>, which says:> Multicast DNS is a way of using familiar DNS programming interfaces, packet formats and operating semantics, in a small network where no conventional DNS server has been installed.BR /Martin ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Yclept Nemo wrote:> Also, just for the record, I actually am serious about using Shorewall. > It is just that even though Shorewall/netfilter *does* run correctly, > I want to know why and how. >Then my next suggestion would be for you to start looking at the output of "shorewall dump" with the help of the following: - http://www.shorewall.net/NetfilterOverview.html - http://www.shorewall.net/PacketHandling.html -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/