Results 1 to 7 of 7

Thread: Routing issues on openSuSE 13.1

  1. #1

    Default Routing issues on openSuSE 13.1

    Greetings!

    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
    Code:
    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).

    Any idea what could be going wrong here?

  2. #2
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    13,295
    Blog Entries
    2

    Default Re: Routing issues on openSuSE 13.1

    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.

    TSU

  3. #3
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    13,295
    Blog Entries
    2

    Default Re: Routing issues on openSuSE 13.1

    You may need to clarify some things about your setup, eg

    What do you mean by setting up your wireless USB as an AP?
    Are you sure you've configured it as an AP or simply a wireless client?

    It also looks like you're using your mobile phone somehow, possibly <that> is your WiFi AP?

    TSU

  4. #4

    Default Re: Routing issues on openSuSE 13.1

    Quote Originally Posted by tsu2 View Post
    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.

    TSU
    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.

    Quote Originally Posted by tsu2 View Post
    You may need to clarify some things about your setup, eg

    What do you mean by setting up your wireless USB as an AP?
    Are you sure you've configured it as an AP or simply a wireless client?

    It also looks like you're using your mobile phone somehow, possibly <that> is your WiFi AP?

    TSU
    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.

  5. #5

    Default Re: Routing issues on openSuSE 13.1

    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...

  6. #6

    Default Re: Routing issues on openSuSE 13.1

    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?

    Right now I'm thoroughly flustered.

  7. #7

    Default [Solved] Routing issues on openSuSE 13.1

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •