Hi, I have a remote office connected to the head quarter through openvpn. Works fine, as long as I route every traffic through the vpn. Now I need to set up a splitted tunnel - all traffic to the head quarter must go through the vpn, regular traffic goes directly into the internet. The router in the remote office is a Xen dom0. Routing works. I set up a (testing) rule for doing NAT: iptables -o eth2 -t nat -A POSTROUTING -j SNAT -d x.x.x.x/32 --to-source y.y.y.y I can see the rule in the POSTROUTING chain. But if I do a "tcpdump -i eth2 -n host x.x.x.x", I can see that the packets are not natted. Also "iptables -L -v -n -t nat" shows all counters as 0 (zero) - it looks like my rule does not match any packet. So my question is: are there issues with netfilter and Xen (in my case, still 3.1)? Any hint is appreciated, Rainer _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Fri, Jan 29, 2010 at 4:29 PM, Rainer Sokoll <rainer@sokoll.com> wrote:> So my question is: are there issues with netfilter and Xen (in my case, > still 3.1)? > > Any hint is appreciated,I don''t quite understand what you''re trying to achieve (why are you using NAT over vpn?), but here are some general pointers: - the best practice is to run as little service as possible on dom0. I usually use a dedicated domU if I need a router/firewall. - having dom0 as firewall can be a little complicated (although possible) when you use the default bridged setup due to device name changes. I usually use OS networking scripts to create bridges. Also be careful about filtering bridged traffic. - looking at your SNAT example, it might be easier to simply use MASQUARADE. For example, this is what network-manager does when you create an ad-hoc wireless network: /sbin/iptables --table nat --insert POSTROUTING --source 10.42.43.0/255.255.255.0 --destination ! 10.42.43.0/255.255.255.0 --jump MASQUERADE - openvpn works just fine on dom0 or domU. Same setup (choice of tun/tap, bridge setup, etc.) that you''d do on a normal box. -- Fajar _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Fri, Jan 29, 2010 at 8:55 PM, Rainer Sokoll <rainer@sokoll.com> wrote:> On Fri, Jan 29, 2010 at 08:34:39PM +0700, Fajar A. Nugraha wrote: > >> I don''t quite understand what you''re trying to achieve (why are you >> using NAT over vpn?), > > There is no NAT over vpn. Routing looks like: > If the target is the companies network, route the packets into the > tunnel, no NAT. > If the target is the internet, route the packets to the ISP''s gateway > and do NAT.so eth2 is the interface to your ISP? Have you set up routing correctly?>> - openvpn works just fine on dom0 or domU. Same setup (choice of >> tun/tap, bridge setup, etc.) that you''d do on a normal box. > > Openvpn is not my problem, it works fine. My problem is that I cannot > get SNAT working. And I am wondering whether Xen could bo the root of my > problem.It shouldn''t be. RHEL/Centos5 comes with Xen 3.1+ and libvirt, which creates virbr0 bridge, which does MASQUARADE for domUs on that bridge. It works as expected. I haven''t tried SNAT on it, but if MASQUARADE works then SNAT should work as well. You might want to try changing the NAT conditions from using "-o eth2" to simply using --source and --destination first, with MASQUARADE for simplicity and easy-debugging. A colleague had some problems a while back, turned out he uses the wrong interface for "-o". -- Fajar _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Fri, Jan 29, 2010 at 09:09:23PM +0700, Fajar A. Nugraha wrote:> You might want to try changing the NAT conditions from using "-o eth2" > to simply using --source and --destination first, with MASQUARADE for > simplicity and easy-debugging. A colleague had some problems a while > back, turned out he uses the wrong interface for "-o".If I follow your instructions, I see the natted (yeah!) packets on vif0.1 - but nothing on eth2 (where the default route sits) - for both SNAT and MASQUERADE. Hm, ist that a step forward? Rainer _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Rainer Sokoll schrieb:> On Fri, Jan 29, 2010 at 09:09:23PM +0700, Fajar A. Nugraha wrote: > >> You might want to try changing the NAT conditions from using "-o eth2" >> to simply using --source and --destination first, with MASQUARADE for >> simplicity and easy-debugging. A colleague had some problems a while >> back, turned out he uses the wrong interface for "-o". > > If I follow your instructions, I see the natted (yeah!) packets on > vif0.1 - but nothing on eth2 (where the default route sits) - for both > SNAT and MASQUERADE.It is getting more strange: brctl show bridge name bridge id STP enabled interfaces xenbr0 8000.000000000000 no xenbr1 8000.00ff746a4f25 no vif0.1 peth1 vif1.0 tap0 As said, if I tcpdump on vif0.1, I see natted packets. But if I tcpdump on xenbr0, I see the same packets, but not natted. I worry that I am missing something fundamental :-( Rainer _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Fri, Jan 29, 2010 at 9:41 PM, Rainer Sokoll <rainer@sokoll.com> wrote:> On Fri, Jan 29, 2010 at 09:09:23PM +0700, Fajar A. Nugraha wrote: > >> You might want to try changing the NAT conditions from using "-o eth2" >> to simply using --source and --destination first, with MASQUARADE for >> simplicity and easy-debugging. A colleague had some problems a while >> back, turned out he uses the wrong interface for "-o". > > If I follow your instructions, I see the natted (yeah!) packets on > vif0.1 - but nothing on eth2 (where the default route sits) - for both > SNAT and MASQUERADE. > Hm, ist that a step forward?Yup, it''s getting somewhere. At this point we need a closer detail on what your setup looks like. I assume you use RHEL/Centos 5 with the default bridge setup? A "brctl show" and "netstat -nr" on dom0 would help. Also a bit explanation on where the packet is coming from. vif0.1 -> that comes as a pair with dom0''s eth1 (which is actually veth1 renamed to eth1, while the real eth1 is renamed to peth1). So assuming the packet comes from outside of dom0 (from domU or other hosts), and dom0 does the routing, it''s safe to say that you have a routing problem: the packets go to eth1 instead of eth2. There''s another possible alternative explanation, one that''s more complicated. In this scenario you have domUs bridged on xenbr1, and they have their own routing setup (NOT go through dom0). But from your previous description this should not be the case. -- Fajar _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Fri, Jan 29, 2010 at 10:05 PM, Rainer Sokoll <r.sokoll@intershop.de> wrote:> Rainer Sokoll schrieb: >> On Fri, Jan 29, 2010 at 09:09:23PM +0700, Fajar A. Nugraha wrote: >> >>> You might want to try changing the NAT conditions from using "-o eth2" >>> to simply using --source and --destination first, with MASQUARADE for >>> simplicity and easy-debugging. A colleague had some problems a while >>> back, turned out he uses the wrong interface for "-o". >> >> If I follow your instructions, I see the natted (yeah!) packets on >> vif0.1 - but nothing on eth2 (where the default route sits) - for both >> SNAT and MASQUERADE. > > It is getting more strange: > > brctl show > bridge name bridge id STP enabled interfaces > xenbr0 8000.000000000000 no > xenbr1 8000.00ff746a4f25 no vif0.1 > peth1 > vif1.0 > tap0That is weird. Usually xenbr0 is connected to vif0.0 and peth0. Did you change the default network-bridge script?> > As said, if I tcpdump on vif0.1, I see natted packets. But if I tcpdump > on xenbr0, I see the same packets, but not natted.That usually means packets come in (or originating from) xenbr0, and routed to eth1 (thus mirrored to vif0.0, and go out the wire from peth1)> I worry that I am missing something fundamental :-(What packets are you using to test, ping from the dom0? from domU? from other hosts on the network? To where? At this point I''d have to say a complete description of your network might be necessary. netstat -nr, iptables -nL, iptables -nL -t nat, and so on. Without that it''s hard to diagnose further. In any case, this is not really xen-specific issue (although the bridge setup might make it a little bit more confusing). You might find it easier to use domU as router/firewall. -- Fajar _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users