After a thorough overhaul (and parallel update to aka. installation from scratch of openSuSE 13.1) of the internal system layout on my notebook (xen, with dom0 being the firewall and guard facility, and the actual workplace is supposed to reside on a virtual machine), the system refuses to properly route any data traffic (I’m currently testing with an USB wifi stick configured as an AP, and associating with it works all right). Since I intend to establish network connectivity via routed networking instead of bridging, I need to verify beforehand that this works…
The situation:
When accessing the 'Net from dom0 everything looks all right, and any packets are sent out to the router linking to the 'Net (reaching the other link-local networks works fine, too).
When linking another box to the AP on my notebook, I can access dom0 without any problems (I even can ping the other interfaces on dom0), but no packets bound for the Internet are forwarded to the outbound connection.
System layout:
Notebook:
SuSEfirewall2 installed and active
FW_ZONE_EXT="wlan0 ppp0" # wlan0 = built-in wifi adaptor, ppp0 = connection to cell phone (when connected)
FW_ZONE_DMZ="wlan1" # wlan1 = USB wifi stick aka. local AP
FW_ZONE_INT="eth0 xeth0" # eth0 = built-in Ethernet adaptor, xeth0 = virtual (dummy) interface to be used by xend
# wlan0: Address and route received via DHCP
# ppp0: Address and route received via DHCP
# wlan1: Static netaddr: 192.168.1.1 (netmask 255.255.255.0) - DHCPd listening here
# eth0: Static netaddr: 192.168.3.1 (netmask 255.255.255.0) - DHCPd listening here
# xeth0: Static netaddr: 192.168.127.1 (netmask 255.255.255.0) - DHCPd listening here
FW_ROUTE="yes"
FW_MASQUERADE="no" # Even the external zone uses private IP addresses!
FW_FORWARD="192.168.1.0/24,0.0.0.0/0,,,zoneout=ext 192.168.3.0/24,0.0.0.0/0,,,zoneout=ext 192.168.127.0/24,0.0.0.0/0,,,zoneout=ext"
I also have enabled IP forwarding when setting up the network interfaces, however, with the firewall down no routing takes place, either. Clearing the zoneout=ext from the forward definitions yields the same results (i. e. failure).
Highly recommend moving this thread to the Virtualization forum since the routing issue has to do with Dom0 (xen) routing, not a typical bare metal install.
I have to object here, because right now I’m currently dealing with real hardware and no virtual devices right now. Since everything takes place in dom0 and no domU are involved, the virtualization forum sould not apply (otherwise I would have posted on the virtulization forum in the first place), and handling of real hardware in dom0 is just about the same as if I were running a non-Xen kernel.
The point is: Since I’m using ifup/ifdown here, I have to del with some problems that I could have averted with Network manager (unfortunately the latter would have prevented me from doing other things like setting up master devices, i. e. ones that other boxes - be it real ones, be it domU guests - connect to).
As far as the interface layout is concerned:
wlan0 = Connects to an AP at home
wlan1 = Access point for other boxes
eth0 = Ethernet card serving as potential master device
ppp0 = Link to my cell phone - which is supposed to serve as a client when I want to hook up to a WLAN when not at home - or, in case one isn’t available, directly to GPRS/UMTS networks…
I have checked both on wlan0 and ppp0 (the latter by doing ifdown wlan0 beforehand), but neither works, although a default rule is set by DHCP when either of the links comes up. With SuSEfirewall2 running, the packets that are supposed to go out to the 'Net are listed to be accepted to the forward chain in /var/log/firewall, but still they aren’t actually forwarded to the outbound connection.
For now, xeth0 can be taken out of the equation, because once I’m going to start working on that one, I would start asking questions on the Virtualization forum. ^^ Right now I would like to resolve the issue of routing not taking place between zone:int (or zone:dmz, respectively) and zone:ext.
Just checked with the default kernel - the result is exactly the same as if I had run the Xen kernel: For some reason nothing is routed.
That should rule out Xen as the cause for these problems…
UPDATE: When enabling masquerading, the entire thing suddenly works - even with private addresses on the external interface… o_O
Now I’m wondering why this detour is necessary even when the external interface points to a network that uses private addresses, too. Normally the system should route the traffic between private networks the same way as if public addresses were used on all involved networks.
Could this be a problem somewhere within the routing code?
I finally managed to figure out the actual problem. Somehow launching hostapd kills any routes that depend on the interface in question (i. e. subnets residing behind the box that attaches to the AP).
A creative abuse of /etc/sysconfig/scripts/SuSEfirewall2-custom helped working around this problem by manually setting the required routes.
