Xen users - Jul 2013 - Dom0 domU bridge problem - virtualizing ISC DHCP server

Here''s the thing.

I want to virtualize DHCP server off one of physical servers to a dedicated
domU under XEN. And the thing does not respond to DHCP requests sent over
broadcast.

The setting:

test - a test server with debian7
togusa - the old physical DHCP server (ISC) with gentoo
dom0 - the dom0 with debian7
domU - the domU with ubuntu 12.04

I have ISC DHCP server installed on every machine. With the same
configuration file. I test it with:
A dhcpcd -T
B dhcping without specifying target DHCP server
C dhcping with target DHCP server specified

With the DHCP server on the togusa server, all four machines can contact
the DHCP server.
With the DHCP server on the "test" server, everything goes as above.
If I start it on the domU or dom0 server, all 4 servers can only contact
the DHCP server with method C.

I have tried it on a numer of XEN dom0/domU servers. All the same. I use
mostly debian 6 or 7 for dom0 with xen 4.1 I believe.

The network card of the physical machine is combined into a bridge with
eth0 on dom0 and corresponding vif interface of the domU. No problems with
TCP/UDP connectivity.

Funny thing - if I ping the broadcast of the network, the dom0 and domU do
not respond.

I have no iptables rules on dom0 or domU. Only the basic provided by debian
(iptables-save from dom0):
-A FORWARD -m state --state RELATED,ESTABLISHED -m physdev --physdev-out
vif17.0 -j ACCEPT
-A FORWARD -p udp -m physdev --physdev-in vif17.0 -m udp --sport 68 --dport
67 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -m physdev --physdev-out
vif17.0 -j ACCEPT
-A FORWARD -s 192.168.0.134/32 -m physdev --physdev-in vif17.0 -j ACCEPT

(0.134 is the address of the domU, I have a feeling that the -dport 67 is
added when xen detects the dhcpserver there)

I do not use etables to filter traffic over the bridge.

Funny thing - If I start the DHCP server on dom0 or domU I can see, that
some printers manage to get an IP address of the server. This seems
ultra-strange.

Where should I start looking? What might be the connectivity problem?

-- 
Pozdrawiam
Jakub Kulesza


_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users

Hello.

El 20/07/13 11:08, Jakub Kulesza escribió:
> Where should I start looking? What might be the connectivity problem?
I would start running tcpdump within DomU and Dom0:
- Find out where the DHCPDICOVER reach, and where they not.
- What is missing, the DHCP requests or answers.
- If a multihomed host is involved, does the packets leaves on the right 
interface?
Does the DHCP server shows something in the log?

I had issues with UDP based services on DomU, specifically with TFTP 
server. Solved by disabling checksuming offload on the virtualized NIC 
"ethtool -K eth0 tx off". It ma be added to the corresponding entry in
/etc/network/interfaces file as "post-up  ethtool -K eth0 tx off".

I do not recall having problems with DHCP server on a DomU, but it has 
been a while since I run dnsmasq almost everywhere, instead of ISC DHCPD.

Greetings.

-- 
Alexandre Kouznetsov

Dear Alexande, I did as you told.

I''ve added following iptables rules to dom0/main router:

-t nat
-A FORWARD -s 192.168.0.0/24 -d 192.168.0.252/32 -i eth0 -p udp -m udp
--dport 67 -j ACCEPT
-A FORWARD -s 192.168.0.0/24 -d 192.168.0.252/32 -i eth0 -p udp -m udp
--dport 68 -j ACCEPT

-t filter
-A FORWARD -d 255.255.255.255/32 -i eth0 -p udp -m udp --dport 67 -j ACCEPT
-A FORWARD -d 255.255.255.255/32 -i eth0 -p udp -m udp --dport 68 -j ACCEPT


0.252 is the address of the DHCP server.

And it works... let''s see how it works out.

THANKS


2013/7/22 Alexandre Kouznetsov <alk@ondore.com>
> Hello.
>
> El 20/07/13 11:08, Jakub Kulesza escribió:
>
>  Where should I start looking? What might be the connectivity problem?
>>
> I would start running tcpdump within DomU and Dom0:
> - Find out where the DHCPDICOVER reach, and where they not.
> - What is missing, the DHCP requests or answers.
> - If a multihomed host is involved, does the packets leaves on the right
> interface?
> Does the DHCP server shows something in the log?
>
> I had issues with UDP based services on DomU, specifically with TFTP
> server. Solved by disabling checksuming offload on the virtualized NIC
> "ethtool -K eth0 tx off". It ma be added to the corresponding
entry in
> /etc/network/interfaces file as "post-up  ethtool -K eth0 tx
off".
>
> I do not recall having problems with DHCP server on a DomU, but it has
> been a while since I run dnsmasq almost everywhere, instead of ISC DHCPD.
>
> Greetings.
>
> --
> Alexandre Kouznetsov
>
>
> ______________________________**_________________
> Xen-users mailing list
> Xen-users@lists.xen.org
> http://lists.xen.org/xen-users
>


-- 
Pozdrawiam
Jakub Kulesza


_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users

Well, that server had 200+ iptables rules, the dom0 routes traffic between
5 interfaces. It must have been something I''ve messed up earlier.

What is your suggestion regarding trimming the rules down?

does this "--physdev-in vif+" and "--physdev-out vif+"
wildcard all vif
interfaces? Would this iptables setting allow for ISC DHCP server to work?

Thanks for help anyway! :D



2013/7/23 Alexandre Kouznetsov <alk@ondore.com>
> Hello.
>
>
> El 22/07/13 16:51, Jakub Kulesza escribió:
>
>  Dear Alexande, I did as you told.
>>
>> I''ve added following iptables rules to dom0/main router:
>>
>> -t nat
>> -A FORWARD -s 192.168.0.0/24 -d 192.168.0.252/32 -i eth0 -p udp -m udp
>> --dport 67 -j ACCEPT
>> -A FORWARD -s 192.168.0.0/24 -d 192.168.0.252/32 -i eth0 -p udp -m udp
>> --dport 68 -j ACCEPT
>>
>> -t filter
>> -A FORWARD -d 255.255.255.255/32 -i eth0 -p udp -m udp --dport 67 -j
>> ACCEPT
>> -A FORWARD -d 255.255.255.255/32 -i eth0 -p udp -m udp --dport 68 -j
>> ACCEPT
>>
>>
>> 0.252 is the address of the DHCP server.
>>
>> And it works... let''s see how it works out.
>>
>
> I''m glad it worked. I have said nothing about iptables, but as you
> describe it, it seems the firewalling on the Dom0 had the fault.
>
>
> The iptables rules you list seems excessive. Good thing it works, but be
> careful not to accumulate too much of this kind of configurations. In
> Debian 6 default installation no additional firewalling is needed in order
> to allow packet forwarding between domains and the physical network. I
> doubt it have changed in Debian 7 (have not tested a clean install yet
> myself).
>
> Since you had to tweak iptables in order to make DHCP working on Dom0, it
> makes me believe there was some firewall rules already applied, which
> prevented DHCP to work at first place. I would suggest fixing that
> firewalling mechanism, instead of patching it with more rules.
>
> As a reference, I''m attaching an example of a basic firewall
script. I use
> something very similar on Dom0 with Debian myself). It runs from
> /etc/network/interfaces, as a post-up for "lo" interface, so it
starts in
> the early beginning.
>
> --
> Alexandre Kouznetsov
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xen.org
> http://lists.xen.org/xen-users
>


-- 
Pozdrawiam
Jakub Kulesza


_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users

Hello.

El 23/07/13 02:09, Jakub Kulesza escribió:
> Well, that server had 200+ iptables rules, the dom0 routes traffic
> between 5 interfaces. It must have been something I''ve messed up
earlier.
I found it more manageable to dedicate a DomU for routing, this way you 
make sure it does not interfere with Dom0 networking.
> What is your suggestion regarding trimming the rules down?
Hm. Not much, after a better look. (:
I would omit the "/32" postfix, unless it simplify the reading for
you.
Also was surprised seeing "-m udp". According to iptables man page
it''s
indeed on it¡s place, but my own rules for DHCP does not use it. I 
specify "-p udp --dport 67" directly.
I would expect only "-t filter" rules to be needed, unless there is 
something very restrictive at the end of "nat" table.
> does this "--physdev-in vif+" and "--physdev-out vif+"
wildcard all vif
> interfaces? Would this iptables setting allow for ISC DHCP server to work?
Yes and yes.
My servers complains in the console about --physdev-in and --physdev-out 
syntax, but I found no solution to fix it and it''s still does
it''s job.
My DHCP server is working on DomU with this iptables configuration on 
Dom0. Instead of ISC DHCP it''s dnsmasq, but don''t I see why it
would not
work with any DHCP daemon.

Greetings.

-- 
Alexandre Kouznetsov