Hallo xen-users! I have a problem with configuration iptables. Whats going wrong? regards Torsten Launoc --------------------------------------------------------------------- 061123.prob.xen.ipt-ml Problem: - after starting firewall (iptables) on eth0, all udp-connections (NFS) broken. - no problem with tcp - after stop firewall, udp already broken. - when i removed any modules, udp going up. Details: ----------------- 192.168.1.2| -| xenU |193.123.123.86 ------------X xen0 |------| eth0| -| xenU | ----------------- l0:~# ./060302.xm_sh_ver Linux l0.rz.example.de 2.6.16-xen0 #2 SMP Mon Jul 17 17:09:35 CEST 2006 i6 86 GNU/Linux Xen version 3.0.2-2 (root@rz.example.de) (gcc version 3.3.5 (Debian 1:3.3.5-13) ) Mon Jul 17 16:03:20 CEST 2006 Latest ChangeSet: Thu Apr 27 14:14:26 2006 +0100 9657:b5d43db15746 l0:~# /etc/init.d/netfilter start Applying iptables firewall rules: ## - udp broken ## but not udp-rules defined: l0:~# iptables -L -n Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTAB LISHED LOG tcp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 23 LOG flags 0 level 7 prefix `INP test: '' DROP tcp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 23 Chain FORWARD (policy ACCEPT) target prot opt source destination ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTAB LISHED LOG tcp -- 0.0.0.0/0 193.123.123.86 multiport dports 2 3 LOG flags 0 level 7 prefix `fwd test: '' DROP tcp -- 0.0.0.0/0 193.123.123.86 multiport dports 2 3 Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain bad_tcp_packets (0 references) target prot opt source destination LOG tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:!0x16/0x0 2 state NEW LOG flags 0 level 7 prefix `bad_tcp New not syn: '' l0:~# l0:~# /etc/init.d/netfilter stop ## - udp already broken l0:~# lsmod Module Size Used by ipt_multiport 2464 4 ipt_LOG 6688 3 xt_state 1952 3 ip_conntrack 43608 1 xt_state xt_tcpudp 3648 1 iptable_filter 2528 1 ip_tables 12276 1 iptable_filter x_tables 10436 5 ipt_multiport,ipt_LOG,xt_state,xt_tcpudp,ip_tabl es bridge 50996 0 sg 28892 0 sworks_agp 7936 0 agpgart 30504 1 sworks_agp e100 34308 0 mii 5088 1 e100 sr_mod 13988 0 cdrom 39072 1 sr_mod l0:~# /etc/init.d/netfilter stop l0:~# rmmod xt_state ip_conntrack ## - udp running! ## ...workaround... ## -> Modul ip_conntrack blocked udp --------------------------------------------------------------------- _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On 11/26/06, Torsten Lehmann <tlehmann@fh-lausitz.de> wrote:> > Hallo xen-users! > > I have a problem with configuration iptables. > Whats going wrong? > > regards Torsten > LaunocDid you try disabling TCP/UDP checksums? http://wiki.xensource.com/xenwiki/XenFaq#head-4ce9767df34fe1c9cf4f85f7e07cb10110eae9b7 _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Mon, 27 Nov 2006, [ISO-8859-1] Abel Martn wrote:> On 11/26/06, Torsten Lehmann <tlehmann@fh-lausitz.de> wrote: > > > > Hallo xen-users! > > > > I have a problem with configuration iptables. > > Whats going wrong? > > > > regards Torsten > > Launoc > > Did you try disabling TCP/UDP checksums? > http://wiki.xensource.com/xenwiki/XenFaq#head-4ce9767df34fe1c9cf4f85f7e07cb10110eae9b7 >## - dump on xenU (client: 123.86, NFSserver=123.85) l1:~# ethtool -K eth0 tx off l1:~# tcpdump -vv -n -i eth0 host NFSserver and udp 17:15:04.814142 IP (tos 0x0, ttl 64, id 65529, offset 0, flags [+], length: 1500) 193.123.123.86.2879998019 > 193.123.123.85.2049: 1472 write [|nfs] 17:15:04.814203 IP (tos 0x0, ttl 64, id 65529, offset 1480, flags [none], length: 720) 193.123.123.86 > 193.123.123.85: udp 17:15:05.266099 IP (tos 0x0, ttl 64, id 65530, offset 0, flags [+], length: 1500) 193.123.123.86.2896775235 > 193.123.123.85.2049: 1472 write [|nfs] 17:15:05.266176 IP (tos 0x0, ttl 64, id 65530, offset 1480, flags [none], length: 720) 193.123.123.86 > 193.123.123.85: udp 17:15:05.714048 IP (tos 0x0, ttl 64, id 65531, offset 0, flags [+], length: 1500) 193.123.123.86.2913552451 > 193.123.123.85.2049: 1472 write [|nfs] 17:15:05.714122 IP (tos 0x0, ttl 64, id 65531, offset 1480, flags [none], length: 720) 193.123.123.86 > 193.123.123.85: udp ## - dump on xen0 l0:~# tcpdump -vv -n -i eth0 host NFSserver and udp ## ... nothing... - xen0:eth0 seen to be blind... Any solutions? regards Torsten Launoc _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On 11/27/06, Torsten Lehmann <tlehmann@fh-lausitz.de> wrote:> l1:~# tcpdump -vv -n -i eth0 host NFSserver and udp > 17:15:04.814142 IP (tos 0x0, ttl 64, id 65529, offset 0, flags [+], > length: 1500) 193.123.123.86.2879998019 > 193.123.123.85.2049: 1472 write > [|nfs] > 17:15:04.814203 IP (tos 0x0, ttl 64, id 65529, offset 1480, flags [none], > length: 720) 193.123.123.86 > 193.123.123.85: udp > 17:15:05.266099 IP (tos 0x0, ttl 64, id 65530, offset 0, flags [+], > length: 1500) 193.123.123.86.2896775235 > 193.123.123.85.2049: 1472 write > [|nfs] > 17:15:05.266176 IP (tos 0x0, ttl 64, id 65530, offset 1480, flags [none], > length: 720) 193.123.123.86 > 193.123.123.85: udp > 17:15:05.714048 IP (tos 0x0, ttl 64, id 65531, offset 0, flags [+], > length: 1500) 193.123.123.86.2913552451 > 193.123.123.85.2049: 1472 write > [|nfs] > 17:15:05.714122 IP (tos 0x0, ttl 64, id 65531, offset 1480, flags [none], > length: 720) 193.123.123.86 > 193.123.123.85: udp >This is telling you that domU''s eth0 interface is not getting any response from NFS server. The problem might reside on domU''s network configuration or dom0 network (don''t think it''s on NFS server networking, althoug you could check to find out more info).> > ## - dump on xen0 > l0:~# tcpdump -vv -n -i eth0 host NFSserver and udp > ## ... nothing... > > - xen0:eth0 seen to be blind...If you''re using Xen bridged networking you should try to run tcpdump on the bridge interface in dom0.> > Any solutions?Might be related to bridged networking when applying iptables rules to a bridged interface (eth0, in your case). If you aren''t using bridged networking I have no idea of what could be happening... In any case your workaround is interesting. Are your sure that this solves the problem or does it go away after waiting for some time? Does your netfilter script play with the interfaces? Could you post its content?> > > regards Torsten > Launoc >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
PAINCHAUD Christophe
2006-Nov-28 08:00 UTC
RE: [Xen-users] Problem start iptables - udp broken
Hello, Did you run ''ethtool -K ethX tx off'' on all your domU interfaces ? Christophe Painchaud On 11/27/06, Torsten Lehmann <tlehmann@fh-lausitz.de> wrote:> l1:~# tcpdump -vv -n -i eth0 host NFSserver and udp > 17:15:04.814142 IP (tos 0x0, ttl 64, id 65529, offset 0, flags [+], > length: 1500) 193.123.123.86.2879998019 > 193.123.123.85.2049: 1472 write > [|nfs] > 17:15:04.814203 IP (tos 0x0, ttl 64, id 65529, offset 1480, flags [none], > length: 720) 193.123.123.86 > 193.123.123.85: udp > 17:15:05.266099 IP (tos 0x0, ttl 64, id 65530, offset 0, flags [+], > length: 1500) 193.123.123.86.2896775235 > 193.123.123.85.2049: 1472 write > [|nfs] > 17:15:05.266176 IP (tos 0x0, ttl 64, id 65530, offset 1480, flags [none], > length: 720) 193.123.123.86 > 193.123.123.85: udp > 17:15:05.714048 IP (tos 0x0, ttl 64, id 65531, offset 0, flags [+], > length: 1500) 193.123.123.86.2913552451 > 193.123.123.85.2049: 1472 write > [|nfs] > 17:15:05.714122 IP (tos 0x0, ttl 64, id 65531, offset 1480, flags [none], > length: 720) 193.123.123.86 > 193.123.123.85: udp >This is telling you that domU''s eth0 interface is not getting any response from NFS server. The problem might reside on domU''s network configuration or dom0 network (don''t think it''s on NFS server networking, althoug you could check to find out more info).> > ## - dump on xen0 > l0:~# tcpdump -vv -n -i eth0 host NFSserver and udp > ## ... nothing... > > - xen0:eth0 seen to be blind...If you''re using Xen bridged networking you should try to run tcpdump on the bridge interface in dom0.> > Any solutions?Might be related to bridged networking when applying iptables rules to a bridged interface (eth0, in your case). If you aren''t using bridged networking I have no idea of what could be happening... In any case your workaround is interesting. Are your sure that this solves the problem or does it go away after waiting for some time? Does your netfilter script play with the interfaces? Could you post its content?> > > regards Torsten > Launoc >lists.xensource.com/xen-users _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On 11/28/06, PAINCHAUD Christophe <cpainchaud@ecritel.net> wrote:> > > > Hello, > > Did you run ''ethtool -K ethX tx off'' on all your domU interfaces ?Yes, he did. Read above...> Christophe Painchaud > > > > On 11/27/06, Torsten Lehmann <tlehmann@fh-lausitz.de> wrote: > > l1:~# tcpdump -vv -n -i eth0 host NFSserver and udp > > 17:15:04.814142 IP (tos 0x0, ttl 64, id 65529, offset 0, flags [+], > > length: 1500) 193.123.123.86.2879998019 > 193.123.123.85.2049: 1472 write > > [|nfs] > > 17:15:04.814203 IP (tos 0x0, ttl 64, id 65529, offset 1480, flags [none], > > length: 720) 193.123.123.86 > 193.123.123.85: udp > > 17:15:05.266099 IP (tos 0x0, ttl 64, id 65530, offset 0, flags [+], > > length: 1500) 193.123.123.86.2896775235 > 193.123.123.85.2049: 1472 write > > [|nfs] > > 17:15:05.266176 IP (tos 0x0, ttl 64, id 65530, offset 1480, flags [none], > > length: 720) 193.123.123.86 > 193.123.123.85: udp > > 17:15:05.714048 IP (tos 0x0, ttl 64, id 65531, offset 0, flags [+], > > length: 1500) 193.123.123.86.2913552451 > 193.123.123.85.2049: 1472 write > > [|nfs] > > 17:15:05.714122 IP (tos 0x0, ttl 64, id 65531, offset 1480, flags [none], > > length: 720) 193.123.123.86 > 193.123.123.85: udp > > > This is telling you that domU''s eth0 interface is not getting any > response from NFS server. The problem might reside on domU''s network > configuration or dom0 network (don''t think it''s on NFS server > networking, althoug you could check to find out more info). > > > > ## - dump on xen0 > > l0:~# tcpdump -vv -n -i eth0 host NFSserver and udp > > ## ... nothing... > > > > - xen0:eth0 seen to be blind... > If you''re using Xen bridged networking you should try to run tcpdump > on the bridge interface in dom0. > > > > Any solutions? > Might be related to bridged networking when applying iptables rules to > a bridged interface (eth0, in your case). If you aren''t using bridged > networking I have no idea of what could be happening... In any case > your workaround is interesting. Are your sure that this solves the > problem or does it go away after waiting for some time? Does your > netfilter script play with the interfaces? Could you post its content? > > > > > > regards Torsten > > Launoc > > > > lists.xensource.com/xen-usersI forgot to ask you. Are you trying to filter traffic for domU in dom0? If you are trying to do this with iptables and Xen bridged networking it has no sense, since a bridged device is a link layer device and iptables works above at network and trasport layer. If you are using Xen routed networking I have no experience with such configuration. Or maybe you are trying to run iptables on domU... Please, provide this info. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Tue, 28 Nov 2006 10:22:53 +0100, Abel Martín wrote> I forgot to ask you. Are you trying to filter traffic for domU in > dom0? If you are trying to do this with iptables and Xen bridged > networking it has no sense, since a bridged device is a link layer > device and iptables works above at network and trasport layer.I hope I''m not hijacking this thread, but what method is recommended to firewall the xen0? Is it illogical to run a bridged network if you want to firewall xen0? Sorry for my ignorance. I''m still learning the ropes. Cheers Bill -- Bill Maidment Maidment Enterprises Pty Ltd www.maidment.vu _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On 11/28/06, Bill Maidment <bill@maidment.vu> wrote:> On Tue, 28 Nov 2006 10:22:53 +0100, Abel Martín wrote > > > I forgot to ask you. Are you trying to filter traffic for domU in > > dom0? If you are trying to do this with iptables and Xen bridged > > networking it has no sense, since a bridged device is a link layer > > device and iptables works above at network and trasport layer. > > I hope I''m not hijacking this thread, but what method is recommended to firewall the > xen0? Is it illogical to run a bridged network if you want to firewall xen0? > Sorry for my ignorance. I''m still learning the ropes. > Cheers > BillWell, you are right. You can use iptables in dom0 to secure domU (xen0). But I think it''s easier to secure domU with an iptables ruleset inside domU, because setting a tightly secure domU inside is more complicated and implies the activation of IP forwarding, with is typical in a router/routed network environment. http://wiki.xensource.com/xenwiki/XenNetworking#head-602e26cd4a03b992f3938fe1bea03fa0fea0ed8b What I tried to say is that firewalling a domU with bridged networking via iptables in dom0 is weird to me. Usually you use bridged networking when domU is in the same network as dom0. Iptables usually filters traffic at network and transport layer, although you can set up restrictions for incoming and outgoing interfaces. You might want to use iptables physdev modules or ebtables to filter at link layer, but the last option is quite rare. I think this matter can be subject for an alternate debate: the best way to secure a domU. What do you think? I may have answered without much thinking. Maybe because I''m used to see iptables running in routers or hosts rather than in bridge devices, although I''ve seen them using physdev iptables module. Sorry if I confused this thread. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Jaroslaw Zdrzalek
2006-Nov-28 11:56 UTC
Re: [Xen-users] Problem start iptables - udp broken
Am Dienstag 28 November 2006 12:10 schrieb Bill Maidment:> On Tue, 28 Nov 2006 10:22:53 +0100, Abel Martín wrote > > > I forgot to ask you. Are you trying to filter traffic for domU in > > dom0? If you are trying to do this with iptables and Xen bridged > > networking it has no sense, since a bridged device is a link layer > > device and iptables works above at network and trasport layer. > > I hope I''m not hijacking this thread, but what method is recommended to firewall the > xen0? Is it illogical to run a bridged network if you want to firewall xen0?the bridge is the most popular approach and it has no or few side effects. When using network-bridge each domain has virtual interfaces connected to a virtual switch. No routing is required nor specail handling like nat in the dom0. The domain0 is like any other domain regarding firewalling: apply your rules to virtual interfaces (eth0, eth1). Do not try to filter on pethX or the bridge having a little or limited knowledge.> Sorry for my ignorance. I''m still learning the ropes. > Cheers > Bill > > -- > Bill Maidment > Maidment Enterprises Pty Ltd > www.maidment.vu > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >Cheers Jaroslaw _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Tue, 28 Nov 2006, [ISO-8859-1] Abel Martn wrote: ....> I forgot to ask you. Are you trying to filter traffic for domU in > dom0? If you are trying to do this with iptables and Xen bridged > networking it has no sense, since a bridged device is a link layer > device and iptables works above at network and trasport layer. If you > are using Xen routed networking I have no experience with such > configuration.Oh yes... I also assumed so far eth0 sees everything. Now i read xenwiki/XenNetworking and understand...perhaps. (see question in my reply on "11/28/06, Bill Maidment") iptables-rules was not bind expilizit to an interface. ...lamp ligths on... I also tested which is, if I bind iptables expilizit an peth0. --------------------------------------------------------------------- EXTIF="peth0" $IPTABLES -i $EXTIF -A INPUT -p tcp -s 0/0 -m multiport --dport 23 -j LOG $LOG_LEVEL --log-prefix "IN test: " $IPTABLES -i $EXTIF -A INPUT -p tcp -s 0/0 -m multiport --dport 23 -j DROP $IPTABLES -i $EXTIF -A FORWARD -p tcp -s 0/0 -d 193.123.123.86 -m multiport --dport 23 -j LOG $LOG_LEVEL --log-prefix "fw nas: " $IPTABLES -i $EXTIF -A FORWARD -p tcp -s 0/0 -d 193.123.123.86 -m multiport --dport 23 -j DROP --------------------------------------------------------------------- - l0:vif2.0 and l1:eth0 captured to same time only - testcommand: $ ls -laR ~ l0:~# tcpdump -vv -n -i peth0 host nfsserver and udp 08:02:47.777591 IP (tos 0x0, ttl 255, id 38933, offset 0, flags [DF], length: 140) 193.123.123.85.2049 > 193.123.123.86.803770947: reply ok 112 getattr DIR 7 55 ids 1104/110 [|nfs] 08:02:47.778281 IP (tos 0x0, ttl 64, id 13432, offset 0, flags [DF], length: 140) 193.123.123.86.820548163 > 193.123.123.85.2049: 112 access [|nfs] 08:02:47.778517 IP (tos 0x0, ttl 255, id 38934, offset 0, flags [DF], length: 148) 193.123.123.85.2049 > 193.123.123.86.820548163: reply ok 120 access attr: DIR 755 ids 1104/110 [|nfs] 08:02:47.779239 IP (tos 0x0, ttl 64, id 13433, offset 0, flags [DF], length: 160) 193.123.123.86.837325379 > 193.123.123.85.2049: 132 readdirplus [|nfs] 08:02:47.780179 IP (tos 0x0, ttl 255, id 38935, offset 0, flags [+, DF], length: 1500) 193.123.123.85.2049 > 193.123.123.86.837325379: reply ok 1472 readdirp lus POST: DIR 755 ids 1104/110 [|nfs] 08:02:47.780198 IP (tos 0x0, ttl 255, id 38935, offset 1480, flags [DF], length: 116) 193.123.123.85 > 193.123.123.86: udp 08:02:49.368860 IP (tos 0x0, ttl 64, id 13434, offset 0, flags [DF], length: 160) 193.123.123.86.837325379 > 193.123.123.85.2049: 132 readdirplus [|nfs] 08:02:49.369606 IP (tos 0x0, ttl 255, id 38936, offset 0, flags [+, DF], length: 1500) 193.123.123.85.2049 > 193.123.123.86.837325379: reply ok 1472 readdirp lus POST: DIR 755 ids 1104/110 [|nfs] 08:02:49.369631 IP (tos 0x0, ttl 255, id 38936, offset 1480, flags [DF], length: 116) 193.123.123.85 > 193.123.123.86: udp 08:02:52.568438 IP (tos 0x0, ttl 64, id 13435, offset 0, flags [DF], length: 160) 193.123.123.86.837325379 > 193.123.123.85.2049: 132 readdirplus [|nfs] 08:02:52.569225 IP (tos 0x0, ttl 255, id 38937, offset 0, flags [+, DF], length: 1500) 193.123.123.85.2049 > 193.123.123.86.837325379: reply ok 1472 readdirp lus POST: DIR 755 ids 1104/110 [|nfs] 08:02:52.569245 IP (tos 0x0, ttl 255, id 38937, offset 1480, flags [DF], length: 116) 193.123.123.85 > 193.123.123.86: udp ## vif="vif`xm list | grep vm3 | awk ''{ print $2}''`.0" l0:~# tcpdump -vv -n -i vif2.0 host nfsserver and udp 08:03:18.118795 IP (tos 0x0, ttl 64, id 16811, offset 0, flags [DF], length: 140) 193.123.123.86.1626706499 > 193.123.123.85.2049: 112 access [|nfs] 08:03:18.119052 IP (tos 0x0, ttl 255, id 42340, offset 0, flags [DF], length: 148) 193.123.123.85.2049 > 193.123.123.86.1626706499: reply ok 120 access attr: DIR 755 ids 1104/110 [|nfs] 08:03:18.119796 IP (tos 0x0, ttl 64, id 16812, offset 0, flags [DF], length: 136) 193.123.123.86.1643483715 > 193.123.123.85.2049: 108 getattr [|nfs] 08:03:18.120072 IP (tos 0x0, ttl 255, id 42341, offset 0, flags [DF], length: 140) 193.123.123.85.2049 > 193.123.123.86.1643483715: reply ok 112 getattr REG 644 ids 1104/110 [|nfs] 08:03:18.120813 IP (tos 0x0, ttl 64, id 16813, offset 0, flags [DF], length: 136) 193.123.123.86.1660260931 > 193.123.123.85.2049: 108 getattr [|nfs] 08:03:18.121081 IP (tos 0x0, ttl 255, id 42342, offset 0, flags [DF], length: 140) 193.123.123.85.2049 > 193.123.123.86.1660260931: reply ok 112 getattr REG 644 ids 1104/110 [|nfs] 08:03:18.121790 IP (tos 0x0, ttl 64, id 16814, offset 0, flags [DF], length: 136) 193.123.123.86.1677038147 > 193.123.123.85.2049: 108 getattr [|nfs] 08:03:18.122050 IP (tos 0x0, ttl 255, id 42343, offset 0, flags [DF], length: 140) 193.123.123.85.2049 > 193.123.123.86.1677038147: reply ok 112 getattr REG 644 ids 1104/110 [|nfs] 08:03:18.122710 IP (tos 0x0, ttl 64, id 16815, offset 0, flags [DF], length: 136) 193.123.123.86.1693815363 > 193.123.123.85.2049: 108 getattr [|nfs] 08:03:18.122969 IP (tos 0x0, ttl 255, id 42344, offset 0, flags [DF], length: 140) 193.123.123.85.2049 > 193.123.123.86.1693815363: reply ok 112 getattr REG 755 ids 1104/110 [|nfs] 08:03:18.123604 IP (tos 0x0, ttl 64, id 16816, offset 0, flags [DF], length: 136) 193.123.123.86.1710592579 > 193.123.123.85.2049: 108 getattr [|nfs] 0) 193.123.123.85.2049 > 193.123.123.86.1710592579: reply ok 112 getattr REG 644 ids 1104/110 [|nfs] 08:03:18.125002 IP (tos 0x0, ttl 64, id 16817, offset 0, flags [DF], length: 136) 193.123.123.86.1727369795 > 193.123.123.85.2049: 108 getattr [|nfs] 08:03:18.125249 IP (tos 0x0, ttl 255, id 42346, offset 0, flags [DF], length: 140) 193.123.123.85.2049 > 193.123.123.86.1727369795: reply ok 112 getattr REG 644 ids 1104/110 [|nfs] 08:03:18.125899 IP (tos 0x0, ttl 64, id 16818, offset 0, flags [DF], length: 136) 193.123.123.86.1744147011 > 193.123.123.85.2049: 108 getattr [|nfs] 08:03:18.126161 IP (tos 0x0, ttl 255, id 42347, offset 0, flags [DF], length: 140) 193.123.123.85.2049 > 193.123.123.86.1744147011: reply ok 112 getattr REG 644 ids 1104/110 [|nfs] 08:03:18.126794 IP (tos 0x0, ttl 64, id 16819, offset 0, flags [DF], length: 136) 193.123.123.86.1760924227 > 193.123.123.85.2049: 108 getattr [|nfs] 08:03:18.127053 IP (tos 0x0, ttl 255, id 42348, offset 0, flags [DF], length: 140) 193.123.123.85.2049 > 193.123.123.86.1760924227: reply ok 112 getattr REG 644 ids 1104/110 [|nfs] 08:03:18.127759 IP (tos 0x0, ttl 64, id 16820, offset 0, flags [DF], length: 136) 193.123.123.86.1777701443 > 193.123.123.85.2049: 108 getattr [|nfs] 08:03:18.128021 IP (tos 0x0, ttl 255, id 42349, offset 0, flags [DF], length: 140) 193.123.123.85.2049 > 193.123.123.86.1777701443: reply ok 112 getattr REG 644 ids 1104/110 [|nfs] 08:03:18.128688 IP (tos 0x0, ttl 64, id 16821, offset 0, flags [DF], length: 136) 193.123.123.86.1794478659 > 193.123.123.85.2049: 108 getattr [|nfs] 08:03:18.128950 IP (tos 0x0, ttl 255, id 42350, offset 0, flags [DF], length: 140) 193.123.123.85.2049 > 193.123.123.86.1794478659: reply ok 112 getattr REG 644 ids 1104/110 [|nfs] 08:03:18.129660 IP (tos 0x0, ttl 64, id 16822, offset 0, flags [DF], length: 136) 193.123.123.86.1811255875 > 193.123.123.85.2049: 108 getattr [|nfs] 08:03:18.129919 IP (tos 0x0, ttl 255, id 42351, offset 0, flags [DF], length: 140) 193.123.123.85.2049 > 193.123.123.86.1811255875: reply ok 112 getattr REG 644 ids 1104/110 [|nfs] 08:03:18.131141 IP (tos 0x0, ttl 64, id 16823, offset 0, flags [DF], length: 136) 193.123.123.86.1828033091 > 193.123.123.85.2049: 108 getattr [|nfs] l1:~# tcpdump -vv -n -i eth0 host nfsserver and udp 08:03:18.118610 IP (tos 0x0, ttl 255, id 42339, offset 0, flags [DF], length: 140) 193.123.123.85.2049 > 193.123.123.86.1609929283: reply ok 112 getattr DIR 755 ids 1104/110 [|nfs] 08:03:18.118752 IP (tos 0x0, ttl 64, id 16811, offset 0, flags [DF], length: 140) 193.123.123.86.1626706499 > 193.123.123.85.2049: 112 access [|nfs] 08:03:18.119404 IP (tos 0x0, ttl 255, id 42340, offset 0, flags [DF], length: 148) 193.123.123.85.2049 > 193.123.123.86.1626706499: reply ok 120 access attr: DIR 755 ids 1104/110 [|nfs] 08:03:18.119745 IP (tos 0x0, ttl 64, id 16812, offset 0, flags [DF], length: 136) 193.123.123.86.1643483715 > 193.123.123.85.2049: 108 getattr [|nfs] 08:03:18.120688 IP (tos 0x0, ttl 64, id 16813, offset 0, flags [DF], length: 136) 193.123.123.86.1660260931 > 193.123.123.85.2049: 108 getattr [|nfs] 08:03:18.121740 IP (tos 0x0, ttl 64, id 16814, offset 0, flags [DF], length: 136) 193.123.123.86.1677038147 > 193.123.123.85.2049: 108 getattr [|nfs] 08:03:18.122663 IP (tos 0x0, ttl 64, id 16815, offset 0, flags [DF], length: 136) 193.123.123.86.1693815363 > 193.123.123.85.2049: 108 getattr [|nfs] 08:03:18.123557 IP (tos 0x0, ttl 64, id 16816, offset 0, flags [DF], length: 136) 193.123.123.86.1710592579 > 193.123.123.85.2049: 108 getattr [|nfs] 08:03:18.377483 IP (tos 0x0, ttl 64, id 16828, offset 0, flags [DF], length: 160) 193.123.123.86.1895141955 > 193.123.123.85.2049: 132 readdirplus [|nfs] 08:03:18.865407 IP (tos 0x0, ttl 64, id 16829, offset 0, flags [DF], length: 160) 193.123.123.86.1895141955 > 193.123.123.85.2049: 132 readdirplus [|nf --------------------------------------------------------------------------- - If one has very much time, then one sees also from time to time any packets in both directions.... -> udp-packets not blocked generally. - Why the knot only solved after that to remove the module ip_conntrack? - to reproduce this problem is sufficient: # modprobe ip_conntrack> > Or maybe you are trying to run iptables on domU... Please, provide this info. >unpractically. Server is in productive use. (i must also to compile modules and new a kernel and reboot all VM) regards Torsten launoc _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Tue, 28 Nov 2006, [ISO-8859-1] Abel Martín wrote:> On 11/28/06, Bill Maidment <bill@maidment.vu> wrote: > > On Tue, 28 Nov 2006 10:22:53 +0100, Abel Martín wrote > > > > > I forgot to ask you. Are you trying to filter traffic for domU in > > > dom0? If you are trying to do this with iptables and Xen bridged > > > networking it has no sense, since a bridged device is a link layer > > > device and iptables works above at network and trasport layer. > > > > I hope I''m not hijacking this thread, but what method is recommended to firewall the > > xen0? Is it illogical to run a bridged network if you want to firewall xen0? > > Sorry for my ignorance. I''m still learning the ropes. > > Cheers > > Bill > Well, you are right. You can use iptables in dom0 to secure domU > (xen0). But I think it''s easier to secure domU with an iptables > ruleset inside domU, because setting a tightly secure domU inside is > more complicated and implies the activation of IP forwarding, with is > typical in a router/routed network environment. > http://wiki.xensource.com/xenwiki/XenNetworking#head-602e26cd4a03b992f3938fe1bea03fa0fea0ed8b > > What I tried to say is that firewalling a domU with bridged networking > via iptables in dom0 is weird to me. Usually you use bridged > networking when domU is in the same network as dom0. Iptables usually > filters traffic at network and transport layer, although you can set > up restrictions for incoming and outgoing interfaces. You might want > to use iptables physdev modules or ebtables to filter at link layer, > but the last option is quite rare. > > I think this matter can be subject for an alternate debate: the best > way to secure a domU. What do you think? I may have answered without > much thinking. Maybe because I''m used to see iptables running in > routers or hosts rather than in bridge devices, although I''ve seen > them using physdev iptables module. > > Sorry if I confused this thread. >did I understand it correctly? I can on Dom0 filter packets to Dom1, when iptables bind to Dom0:peth0 or Dom0:vif1.0 . Dom0 Dom1 ---- ---- eth0 | eth0 vif1.0 | | -------------... Bridge | peth0 | if iptables run without "-i dev", default will bind to eth0. It sees no packets from peth0 to Dom1:eth0. On xenwiki/XenNetworking i found docu to configuration "bridging" and "routing". Where find I information too Pro and Contra? (bridging vs. routing) regards Torsten Launoc _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On 11/29/06, Torsten Lehmann <tlehmann@fh-lausitz.de> wrote:> did I understand it correctly? > I can on Dom0 filter packets to Dom1, when iptables bind to Dom0:peth0 > or Dom0:vif1.0 . > > > > Dom0 Dom1 > ---- ---- > > eth0 > | > eth0 vif1.0 > | | > -------------... Bridge > | > peth0 > | > > > if iptables run without "-i dev", default will bind to eth0. > It sees no packets from peth0 to Dom1:eth0. >If you want to filter traffic for domU in dom0 I would do something similar to what is recommended on Xen Networking wiki with a slight difference. # create a chain for rules for your domU iptables -N domU # process domU rules if traffic enters/leaves physical net device eth0 but doesn''t leaves/enters it iptables -A FORWARD -m physdev --physdev-in eth0 --physdev-out ''!'' eth0 -j domU iptables -A FORWARD -m physdev --physdev-out eth0 --physdev-in ''!'' eth0 -j domU # create specific rules for your domU iptables -A domU -m udp -p udp --sport 1024:65535 --dport 2049 --source $trusted_IPs --destination $NFS_IP -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A domU -m udp -p udp --destination $trusted_IPs --source $NFS_IP --sport 2049 --dport 1024:65535 -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A domU -j DROP I''ve tested this rules with netcat and it works on my machine, although they don''t prevent accessing any service in domU from dom0. Don''t know if your problem has to do with ip_conntrack or NFS itself. I''m using Xen 2.6.18 in a Debian Sid box. A curious thing that I found is that running tcpdump in dom0''s bridge or eth0 only show incoming packets, as you mentioned before. Surprisingly the same applies to vif1.0. The traffic flows in both directions, though. Maybe a libpcap or tcpdump problem? So tcpdump might not be the right tool to analyze this problem. Watch out if you have rules in PREROUTING, FORWARD and POSTROUTING chains, as stated in: http://wiki.xensource.com/xenwiki/XenNetworking#head-602e26cd4a03b992f3938fe1bea03fa0fea0ed8b The script you''re executing might not suit your needs.> > > > On xenwiki/XenNetworking i found docu to configuration "bridging" and > "routing". > Where find I information too Pro and Contra? (bridging vs. routing) >Bridging is the default networking setup for Xen. I''ve never worked with routed networking in Xen, so I can''t give you any useful opinion. Regards. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Torsten Lehmann
2006-Nov-29 15:15 UTC
Re: [Xen-users] Problem start iptables - udp broken (Workaround)
On Wed, 29 Nov 2006, Torsten Lehmann wrote:> > - If one has very much time, then one sees also from time to time > any packets in both directions.... > > -> udp-packets not blocked generally. > > - Why the knot only solved after that to remove the module ip_conntrack? > > - to reproduce this problem is sufficient: > # modprobe ip_conntrack >- Workaround: remove ip_conntrack from kernel: # cd xen-3.0-testing/linux-2.6.16-xen0 # find . -name ip_conntrack.ko -exec rm -f {} \; -print # find /lib/modules/`uname -r` -name ip_conntrack.ko -exec rm -f {} \; -print l0# diff .config.old .config ... < CONFIG_IP_NF_CONNTRACK=m> # CONFIG_IP_NF_CONNTRACK is not setl0:# make modules modules_install l0:# /etc/init.d/netfilter start Applying iptables firewall rules: iptables: No chain/target/match by that name iptables: No chain/target/match by that name iptables: No chain/target/match by that name - "No chain...": rules which need ip_conntrack - following rule-set was tested: $IPTABLES -i $EXTIF -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # -> iptables: No chain/target/match by that name # "--state" required ip_conntrack $IPTABLES -A FORWARD -m physdev --physdev-in eth0 --physdev-out ''!'' eth0 -j domU $IPTABLES -A FORWARD -m physdev --physdev-out eth0 --physdev-in ''!'' eth0 -j domU $IPTABLES -A domU -p tcp -s 0/0 -m multiport --dport 23 -j LOG $LOG_LEVEL --log-prefix "IN testdomU: " # -> iptables: No chain/target/match by that name # "-m physdev" required ip_conntrack (??) $IPTABLES -i peth0 -A INPUT -p tcp -s 0/0 -m multiport --dport 23 -j LOG $LOG _LEVEL --log-prefix "IN testpeth: " # -> nomatch...rule not working $IPTABLES -A INPUT -p tcp -s 0/0 -m multiport --dport 23 -j LOG $LOG_LEVEL --log-prefix "IN test: " # -> match....OK regards Torsten Launoc _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Abel Martín
2006-Nov-29 15:37 UTC
Re: [Xen-users] Problem start iptables - udp broken (Workaround)
11/29/06, Torsten Lehmann <tlehmann@fh-lausitz.de> wrote:> On Wed, 29 Nov 2006, Torsten Lehmann wrote: > > > > > - If one has very much time, then one sees also from time to time > > any packets in both directions.... > > > > -> udp-packets not blocked generally. > > > > - Why the knot only solved after that to remove the module ip_conntrack? > > > > - to reproduce this problem is sufficient: > > # modprobe ip_conntrack > > > > - Workaround: remove ip_conntrack from kernel: > > # cd xen-3.0-testing/linux-2.6.16-xen0 > # find . -name ip_conntrack.ko -exec rm -f {} \; -print > # find /lib/modules/`uname -r` -name ip_conntrack.ko -exec rm -f {} \; -print > > l0# diff .config.old .config > ... > < CONFIG_IP_NF_CONNTRACK=m > > # CONFIG_IP_NF_CONNTRACK is not set > > l0:# make modules modules_install > > l0:# /etc/init.d/netfilter start > Applying iptables firewall rules: > iptables: No chain/target/match by that name > iptables: No chain/target/match by that name > iptables: No chain/target/match by that name > - "No chain...": rules which need ip_conntrack > > - following rule-set was tested: > > $IPTABLES -i $EXTIF -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT > # -> iptables: No chain/target/match by that name > # "--state" required ip_conntrack > > $IPTABLES -A FORWARD -m physdev --physdev-in eth0 --physdev-out ''!'' eth0 -j domU > $IPTABLES -A FORWARD -m physdev --physdev-out eth0 --physdev-in ''!'' eth0 -j domU > $IPTABLES -A domU -p tcp -s 0/0 -m multiport --dport 23 -j LOG $LOG_LEVEL --log-prefix "IN testdomU: " > # -> iptables: No chain/target/match by that name > # "-m physdev" required ip_conntrack (??)Did you create the chain named domU with "iptables -N domU"? The iptables state module won''t work without the conntrack module. Please, don''t disable ip_conntrack and don''t just copy and paste the rules I sent. Adapt them to your needs. In my box there''s no peth0, but eth0. This is because the way networking scripts configure Xen networking depending on the Xen package one installs.> > $IPTABLES -i peth0 -A INPUT -p tcp -s 0/0 -m multiport --dport 23 -j LOG $LOG _LEVEL --log-prefix "IN testpeth: " > # -> nomatch...rule not working > > $IPTABLES -A INPUT -p tcp -s 0/0 -m multiport --dport 23 -j LOG $LOG_LEVEL --log-prefix "IN test: " > # -> match....OK > > > regards Torsten > Launoc > >Regards. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Torsten Lehmann
2006-Nov-30 07:19 UTC
Re: [Xen-users] Problem start iptables - udp broken (Workaround)
On Wed, 29 Nov 2006, [ISO-8859-1] Abel Martín wrote:> 11/29/06, Torsten Lehmann <tlehmann@fh-lausitz.de> wrote: > > On Wed, 29 Nov 2006, Torsten Lehmann wrote: > > > > > > > > - If one has very much time, then one sees also from time to time > > > any packets in both directions.... > > > > > > -> udp-packets not blocked generally. > > > > > > - Why the knot only solved after that to remove the module ip_conntrack? > > > > > > - to reproduce this problem is sufficient: > > > # modprobe ip_conntrack > > > > > > > - Workaround: remove ip_conntrack from kernel: > > > > # cd xen-3.0-testing/linux-2.6.16-xen0 > > # find . -name ip_conntrack.ko -exec rm -f {} \; -print > > # find /lib/modules/`uname -r` -name ip_conntrack.ko -exec rm -f {} \; -print > > > > l0# diff .config.old .config > > ... > > < CONFIG_IP_NF_CONNTRACK=m > > > # CONFIG_IP_NF_CONNTRACK is not set > > > > l0:# make modules modules_install > > > > l0:# /etc/init.d/netfilter start > > Applying iptables firewall rules: > > iptables: No chain/target/match by that name > > iptables: No chain/target/match by that name > > iptables: No chain/target/match by that name > > - "No chain...": rules which need ip_conntrack > > > > - following rule-set was tested: > > > > $IPTABLES -i $EXTIF -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT > > # -> iptables: No chain/target/match by that name > > # "--state" required ip_conntrack > > > > $IPTABLES -A FORWARD -m physdev --physdev-in eth0 --physdev-out ''!'' eth0 -j domU > > $IPTABLES -A FORWARD -m physdev --physdev-out eth0 --physdev-in ''!'' eth0 -j domU > > $IPTABLES -A domU -p tcp -s 0/0 -m multiport --dport 23 -j LOG $LOG_LEVEL --log-prefix "IN testdomU: " > > # -> iptables: No chain/target/match by that name > > # "-m physdev" required ip_conntrack (??) > > Did you create the chain named domU with "iptables -N domU"? TheYes. I dit it.> iptables state module won''t work without the conntrack module. Please, > don''t disable ip_conntrack and don''t just copy and paste the rules I > sent. Adapt them to your needs. In my box there''s no peth0, but eth0. > This is because the way networking scripts configure Xen networking > depending on the Xen package one installs.But, if I load the module "ip_conntrack" only (without set a iptables-rule), the network (udp) is broken! <ot>Load a Modules into kernel should never cause trouble.</ot> regards Torsten Launoc _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Abel Martín
2006-Nov-30 09:28 UTC
Re: [Xen-users] Problem start iptables - udp broken (Workaround)
On 11/30/06, Torsten Lehmann <tlehmann@fh-lausitz.de> wrote:> Yes. I dit it. > > But, if I load the module "ip_conntrack" only (without set a iptables-rule), > the network (udp) is broken! > <ot>Load a Modules into kernel should never cause trouble.</ot> > > > regards Torsten > Launoc >Sorry if I sounded a bit rude. I think you should try on a different box with a minimal setup and the same kernel to do some tests. If the problem persist, maybe you should try asking people who created this kernel or in last instance netfilter people, but you must be sure before asking. Provide the software versions you are using (kernel, iptables, Xen, etc.) Since this problem doesn''t seem to happen with other kernel versions might be a problem caused by the kernel you are using. By the way, which kernel version are you using and where did you get it? Regards. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Torsten Lehmann
2006-Nov-30 12:38 UTC
Re: [Xen-users] Problem start iptables - udp broken (Workaround)
On Thu, 30 Nov 2006, [ISO-8859-1] Abel Martín wrote:> On 11/30/06, Torsten Lehmann <tlehmann@fh-lausitz.de> wrote: > > Yes. I dit it. > > > > But, if I load the module "ip_conntrack" only (without set a iptables-rule), > > the network (udp) is broken! > > <ot>Load a Modules into kernel should never cause trouble.</ot> > > > > > > regards Torsten > > Launoc > > > > Sorry if I sounded a bit rude. I think you should try on a differentNo problem.> box with a minimal setup and the same kernel to do some tests. If theI will test it. It will take some days.> problem persist, maybe you should try asking people who created this > kernel or in last instance netfilter people, but you must be sure > before asking. Provide the software versions you are using (kernel, > iptables, Xen, etc.) Since this problem doesn''t seem to happen with > other kernel versions might be a problem caused by the kernel you are > using. By the way, which kernel version are you using and where did > you get it?I tested so far only these version: l0:~# ./060302.xm_sh_ver Linux l0.rz.example.de 2.6.16-xen0 #2 SMP Mon Jul 17 17:09:35 CEST 2006 i6 86 GNU/Linux Xen version 3.0.2-2 (root@xxxxxxxxxxxxx) (gcc version 3.3.5 (Debian 1:3.3.5-13) ) Mon Jul 17 16:03:20 CEST 2006 Latest ChangeSet: Thu Apr 27 14:14:26 2006 +0100 9657:b5d43db15746 I will test the version xen-3.0.3-testing. regards Torsten _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Abel Martín
2006-Nov-30 14:44 UTC
Re: [Xen-users] Problem start iptables - udp broken (Workaround)
On 11/30/06, Torsten Lehmann <tlehmann@fh-lausitz.de> wrote:> I tested so far only these version: > > l0:~# ./060302.xm_sh_ver > Linux l0.rz.example.de 2.6.16-xen0 #2 SMP Mon Jul 17 17:09:35 CEST 2006 i6 > 86 GNU/Linux > Xen version 3.0.2-2 (root@xxxxxxxxxxxxx) (gcc version 3.3.5 (Debian > 1:3.3.5-13) > ) Mon Jul 17 16:03:20 CEST 2006 > Latest ChangeSet: Thu Apr 27 14:14:26 2006 +0100 9657:b5d43db15746 >Check the gcc version your kernel was compiled with with ''cat /proc/version''. I don''t know if there could be any problem, but I would check that Xen software is compiled with the same gcc version your kernel was. I think 2.6.16 kernels are usually build using gcc 4.x.> > > I will test the version xen-3.0.3-testing. >Which distro are you using? Are you taking the software from packages, binaries or source code?> > regards Torsten > >Regards. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users