Hello, i have a problem with masquarading traffic which i can''t solve - so if anyone give me a hint, that would be very appreciated! I have a machine with running Xen 3.0 - Dom0 is acting as firewall and additonally has an open connection to an openvpn server (Dom0 has full access to the vpn and all machines in the vpn-network - works all pretty well). My DomU should be able to reach the vpn-network (192.168.1.0/24), as well ... therefor i''m routing all traffic from DomU to Dom0 - and Dom0 shold send the traffic to the vpn-network - IMHO this should be a "traditional gateway szenario" ?! Basically this works ... but: The source of the traffic from the DomU is the IP of the DomU (192.168.72.186) ... therefore the machines in the vpn-network are not able to respond, as they don''t know that net. I tried to add the following line to /etc/shorewall/masq tun0 192.168.72.186/32 192.168.10.241 I supposed that this line would masquarade all traffic through tun0 with the VPN-address of Dom0 - but for any reason, this does not happen ... tcpdump shows still 192.168.72.186 as the source-IP. What i''m i doing wrong? Thanks for any hint! Christian
On Thursday 09 March 2006 03:12, Christian Hobelsberger wrote:> Hello, > > i have a problem with masquarading traffic which i can''t solve - so if > anyone give me a hint, that would be very appreciated! > > I have a machine with running Xen 3.0 - Dom0 is acting as firewall and > additonally has an open connection to an openvpn server (Dom0 has full > access to the vpn and all machines in the vpn-network - works all pretty > well). > > My DomU should be able to reach the vpn-network (192.168.1.0/24), as well > ... therefor i''m routing all traffic from DomU to Dom0 - and Dom0 shold > send the traffic to the vpn-network - IMHO this should be a "traditional > gateway szenario" ?! > > Basically this works ... but: The source of the traffic from the DomU is > the IP of the DomU (192.168.72.186) ... therefore the machines in the > vpn-network are not able to respond, as they don''t know that net. > > I tried to add the following line to /etc/shorewall/masq > tun0 192.168.72.186/32 192.168.10.241 > I supposed that this line would masquarade all traffic through tun0 with > the VPN-address of Dom0 - but for any reason, this does not happen ... > tcpdump shows still 192.168.72.186 as the source-IP. > > What i''m i doing wrong?Nothing that I can see, Cristian. That''s why we ask that you give us full information about your setup when you post a problem (see http://www.shorewall.net/support.htm). If you only send us the information you think is relevant then we get to see your problem filtered through your understanding of it. Be that as it may, can you push a route to 192.168.72.186 when the tunnel comes up (see the OpenVPN documentation)? If that will work (you haven''t mentioned what the routing at the remote gateway looks like), you don''t have to use any address rewriting hacks. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Hi Tom, thank you for you response ... Nothing that I can see, Cristian. That''s why we ask that you give us full> information about your setup when you post a problem (see > http://www.shorewall.net/support.htm). If you only send us the information > you think is relevant then we get to see your problem filtered through > your > understanding of it.sorry :( i considered my problem to be very simple ... Here more information (please see attached file for even more). My szenario consists of 4 machines: "openvpn" - this is the openvpn-server. The machine lives in the 192.168.1.0/24 network - openvpn uses the 192.168.10.0/24. The machines grants access to the network 192.168.1.0 to all machines connected through the vpn. "puntacana" - this is the Dom0 (for this machine i attached a file with additional infos) - on this machine shorewall is running. The rules/policies of shorewall are all to "accept" - interface, host and zone settings are attached. I know that the "setup" of shorewall is not acceptable, but shorewall currently does not need to "filter" - just let all traffic pass. puntacana is part of network 192.168.72.0/24 with IP 192.168.72.180 and 192.168.5.0/24 with IP 192.168.5.180 - additonially puntanaca is connected with openvpn to 192.168.10.0. openvpn pushes a route to a network 192.168.1.0/24 to puntacana, so puntacana has a connection to that network, too. Connecting to 192.168.1.0/24 works without a problem. "XenTestServer" - this is the DomU machine ... the machine lives in a network 192.168.72.0/24 with IP 192.168.72.186 and in 192.168.5.0/24 with IP 192.168.5.180. Both networks are bridged from dom0 (xenbr0 and xenbr3). XenTestServer should be able to connect to machines in 192.168.1.0/24, therefor i added the route 192.168.1.0 192.168.72.180 255.255.255.0 UG 0 0 0 eth1 to route all traffic to puntacana, which "knows" how to send the packages to that network. (The default-gateway of XenTestServer is 192.168.5.254 - a completly different machine) "server" - this is a server in the 192.168.1.0/24 network (and stands actually for a bunch of servers) - the machine has IP 192.168.1.5. "server" has a route to send packets, originating in the 192.168.10.0/24network, to the openvpn server. Therefor if "puntacana" tries to access " 192.168.1.5" this works without a problem. If "XenTestServers" tries to access "192.168.1.5" it does not work, as "servers" sees, that the packets came from 192.168.72.186 - and to that IP exits no route. (puntacana appears as 192.168.10.241 - because of the openvpn connection). Be that as it may, can you push a route to 192.168.72.186 when the tunnel> comes up (see the OpenVPN documentation)? If that will work (you haven''t > mentioned what the routing at the remote gateway looks like), you don''t > have > to use any address rewriting hacks.yes - this would work. If i would add the needed routes at the openvpn server and at "server" - then it woule be possible to access eg. " 192.168.1.5" from XenTestServer - i had already tried this - but for simpler maintenance i would prefer to have the traffic masquaraded . IMHO the szenario should be almost the same as at a typical firewall with a LAN on eth1 and internet-connection on eth0 ... here i would just tell shorewall that all traffic from eth1 should be masquaraded with the IP of eth0 ... For something i''m not aware of, it does not work such simple here ... :( What reasons are possible, that the traffic is not masquaraded, although /etc/shorewall/masquarade says: tun0 192.168.72.186/32 192.168.10.241 While shorewall starts there is this message: Masqueraded Networks and Hosts: To 0.0.0.0/0 (all) from 192.168.72.186/32 through tun0 using 192.168.10.241 thanks for your time ... Christian
On Thursday 09 March 2006 08:36, Christian Hobelsberger wrote:> Hi Tom, thank you for you response ... > > Nothing that I can see, Cristian. That''s why we ask that you give us full > > > information about your setup when you post a problem (see > > http://www.shorewall.net/support.htm). If you only send us the > > information you think is relevant then we get to see your problem > > filtered through your > > understanding of it. > > sorry :( > i considered my problem to be very simple ...Nothing is simple when you are dealing with Xen Dom0.> > IMHO the szenario should be almost the same as at a typical firewall with a > LAN on eth1 and internet-connection on eth0 ... here i would just tell > shorewall that all traffic from eth1 should be masquaraded with the IP of > eth0 ... > For something i''m not aware of, it does not work such simple here ... :(Are you also seeing messages on your console (or in your logs) complaining about bridges and SNAT? Another Xen user reported problems in this area (a quick search didn''t turn up the thread; sorry) -- it appeared from the evidence in that thread that it was not possible to SNAT from Dom0.> > What reasons are possible, that the traffic is not masquaraded, although > /etc/shorewall/masquarade says: > tun0 192.168.72.186/32 192.168.10.241 > While shorewall starts there is this message: > Masqueraded Networks and Hosts: > To 0.0.0.0/0 (all) from 192.168.72.186/32 through tun0 using > 192.168.10.241Yes -- Shorewall is setting up the correct rule but the traffic doesn''t go through it for some reason. Again, please check your logs. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
On Thursday 09 March 2006 09:44, Tom Eastep wrote:> On Thursday 09 March 2006 08:36, Christian Hobelsberger wrote: > > Hi Tom, thank you for you response ... > > > > Nothing that I can see, Cristian. That''s why we ask that you give us full > > > > > information about your setup when you post a problem (see > > > http://www.shorewall.net/support.htm). If you only send us the > > > information you think is relevant then we get to see your problem > > > filtered through your > > > understanding of it. > > > > sorry :( > > i considered my problem to be very simple ... > > Nothing is simple when you are dealing with Xen Dom0. > > > IMHO the szenario should be almost the same as at a typical firewall with > > a LAN on eth1 and internet-connection on eth0 ... here i would just tell > > shorewall that all traffic from eth1 should be masquaraded with the IP of > > eth0 ... > > For something i''m not aware of, it does not work such simple here ... :( > > Are you also seeing messages on your console (or in your logs) complaining > about bridges and SNAT? Another Xen user reported problems in this area (a > quick search didn''t turn up the thread; sorry) -- it appeared from the > evidence in that thread that it was not possible to SNAT from Dom0. > > > What reasons are possible, that the traffic is not masquaraded, although > > /etc/shorewall/masquarade says: > > tun0 192.168.72.186/32 192.168.10.241 > > While shorewall starts there is this message: > > Masqueraded Networks and Hosts: > > To 0.0.0.0/0 (all) from 192.168.72.186/32 through tun0 using > > 192.168.10.241 > > Yes -- Shorewall is setting up the correct rule but the traffic doesn''t go > through it for some reason. > > Again, please check your logs. >If you don''t see anything in the logs then please try sending some traffic from 192.168.72.186 through the tunnel before capturing another "shorewall dump" output. That way, I can look at packet/byte counts and hopefully I can see something. It doesn''t appear that your situation is the same as the other person''s; IIRC, in the other case, the Dom0 device specified in the /etc/shorewall/masq rule was a backend device that connected through a Xen bridge. In your case, tun0 isn''t bridged. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
2006/3/9, Tom Eastep <teastep@shorewall.net>:> > > Nothing is simple when you are dealing with Xen Dom0.it seems so ... :(> > Again, please check your logs. > > > > If you don''t see anything in the logs then please try sending some traffic > from 192.168.72.186 through the tunnel before capturing another "shorewall > dump" output. That way, I can look at packet/byte counts and hopefully I > can > see something. > >i checked the logs and console - but there are no indicating messages - i have attached two other dumps - maybe you can see something ... I tried to follow the icmp-packages (dump-masq-tun0) from domU to the target ... if it tcpdump on xenbr0, eth0 and tun0 i see always 192.168.72.186 as source-ip ... so no masquarading occurs. just for fun i changed shorewall/masq to masquarade traffic through xenbr0, instead of tun0 (dump-masq-xenbr0) ... tcpdump on xrnbr0 shows 192.168.72.186 as source ... on eth0 tcpdump shows 192.168.10.241, so masquarading occured - but for any reason the packages are not forwarded to tun0 - tcpdump does not show any icmp packets, there ... so i assume the packets get either dropped, or leave the machine on eth0 (although i can not see them arriving on any other machine). I don''t understand it ... maybe this is a xen-bug ... :/ Christian, getting frustrated.