Hi all, maybe this is a seldom need, but we have to route traffic between ipsec zones and openvpn zones. This is on a SUSE 10.1 system with kernel 2.6.16 .... and shorewall 4.0.4. I searched the documentation but couldn''t fin a solution, I tried to define "routeback" option on my openvpn zones, this did not change a thing. As far as I understand this problem, my problem is that there is no virtual device like ipsec0 anymore to which I could add routes to. Openvpn has its "tun" devices, this is no problem, but how to route between these zones ? Any hint is much appreciated ! Regards, - Mit freundlichen Grüßen, Philipp Rusch ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Philipp Rusch wrote:> Hi all, > maybe this is a seldom need, but we have to route traffic between ipsec > zones > and openvpn zones. This is on a SUSE 10.1 system with kernel 2.6.16 .... > and shorewall 4.0.4. I searched the documentation but couldn''t fin a > solution, > I tried to define "routeback" option on my openvpn zones, this did not > change > a thing. As far as I understand this problem, my problem is that there is no > virtual device like ipsec0 anymore to which I could add routes to. Openvpn > has its "tun" devices, this is no problem, but how to route between > these zones ? > Any hint is much appreciated !You simply define SPs on the gateways that require traffic between the two endpoints to be encrypted. Normal routing takes over from there. -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 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Tom Eastep wrote:> Philipp Rusch wrote: >> Hi all, >> maybe this is a seldom need, but we have to route traffic between ipsec >> zones >> and openvpn zones. This is on a SUSE 10.1 system with kernel 2.6.16 .... >> and shorewall 4.0.4. I searched the documentation but couldn''t fin a >> solution, >> I tried to define "routeback" option on my openvpn zones, this did not >> change >> a thing. As far as I understand this problem, my problem is that there is no >> virtual device like ipsec0 anymore to which I could add routes to. Openvpn >> has its "tun" devices, this is no problem, but how to route between >> these zones ? >> Any hint is much appreciated ! > > You simply define SPs on the gateways that require traffic between the two > endpoints to be encrypted. Normal routing takes over from there.Is your problem that the forwarded traffic is being rejected by the firewall as shown in the "Shorewall" log? -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 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Tom Eastep schrieb:> Tom Eastep wrote: > >> Philipp Rusch wrote: >> >>> Hi all, >>> maybe this is a seldom need, but we have to route traffic between ipsec >>> zones >>> and openvpn zones. This is on a SUSE 10.1 system with kernel 2.6.16 .... >>> and shorewall 4.0.4. I searched the documentation but couldn''t fin a >>> solution, >>> I tried to define "routeback" option on my openvpn zones, this did not >>> change >>> a thing. As far as I understand this problem, my problem is that there is no >>> virtual device like ipsec0 anymore to which I could add routes to. Openvpn >>> has its "tun" devices, this is no problem, but how to route between >>> these zones ? >>> Any hint is much appreciated ! >>> >> You simply define SPs on the gateways that require traffic between the two >> endpoints to be encrypted. Normal routing takes over from there. >> > > Is your problem that the forwarded traffic is being rejected by the firewall > as shown in the "Shorewall" log? > > -Tom >Tom, my problem is that traffic is going to the wrong zone. When I try to access hosts in one of ipsec zones while I am sitting in an openvpn zone, my packets travel to "net" and hence don''t find their aim. I have several openvpn tunnels defined in "tunnel", they work fine. I am able to go from one openvpn zone to another openvpn host. I got 60 ipsec tunnels which all go in one zone which I defined in "hosts" file. hosts: #ZONE HOST(S) OPTIONS fil eth1:172:30.0.0/16 ipsec tunnels: #TYPE ZONE GATEWAY GATEWAY ZONE ipsec net 80.152..... ipsec net 80.152..... and so on (many external fixed ips) openvpnserver:5555 net 0.0.0.0/0 #Roadwarrior1 openvpnserver:5556 net 0.0.0.0/0 #Roadwarrior2 etc. zone: #ZONE TYPE OPTIONS IN OUT fil ipsec mode=tunnel mss=1350,proto=esp mss=1350,proto=esp net ipv4 loc ipv4 vpn1 ipv4 vpn2 ipv4 I would expect that packets from vpn1 or vpn2 would go to the "fil" zone if I addressed one of the 172.30.x.y IP-addresses, but they keep travelling to "net". - Philipp ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Philipp Rusch wrote:> > my problem is that traffic is going to the wrong zone. > When I try to access hosts in one of ipsec zones while I am sitting in an > openvpn zone, my packets travel to "net" and hence don''t find their aim. >Your problem is that you don''t understand IPSEC. This is neither a Shorewall problem nor is it a routing problem. As I said in my previous message, you must configure IPSEC to encrypt the traffic -- then AND ONLY THEN will it go to the right destination. -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 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Tom Eastep schrieb:> Philipp Rusch wrote: > > >> my problem is that traffic is going to the wrong zone. >> When I try to access hosts in one of ipsec zones while I am sitting in an >> openvpn zone, my packets travel to "net" and hence don''t find their aim. >> >> > > Your problem is that you don''t understand IPSEC. This is neither a > Shorewall problem nor is it a routing problem. As I said in my previous > message, you must configure IPSEC to encrypt the traffic -- then AND > ONLY THEN will it go to the right destination. > > -Tom > > ------------------------------------------------------------------------Tom, just for clarification: if I have a multihomed host sitting in a LAN with one arm and several openvpn clients on this same host, the packets that the IPSec SA and/or shorewall sees are coming from the wrong "origin" ? So my misunderstanding was that I somehow thought that these OpenVPN- tunnel terminate on the firewall and therefore can fulfill the same SA that I already defined for firewall to IPSec client-tunnels. If I would be able to setup a bridged OpenVPN connection, then those SA''s should match, because the packets from OpenVPN-clients look the same as if they were coming from the internal zone "loc", right ? So my last question is: Is bridging with tap-devices the way to go ? Regards, -- Mit freundlichen Grüßen, Philipp Rusch ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
W dniu 2007-10-05 10:21, Philipp Rusch pisze:> Tom Eastep schrieb: >> Philipp Rusch wrote: >> >> >>> my problem is that traffic is going to the wrong zone. >>> When I try to access hosts in one of ipsec zones while I am sitting in an >>> openvpn zone, my packets travel to "net" and hence don''t find their aim. >>> >>> >> Your problem is that you don''t understand IPSEC. This is neither a >> Shorewall problem nor is it a routing problem. As I said in my previous >> message, you must configure IPSEC to encrypt the traffic -- then AND >> ONLY THEN will it go to the right destination. >> >> -Tom >> >> > Tom, > just for clarification: if I have a multihomed host sitting in a LAN > with one > arm and several openvpn clients on this same host, the packets that > the IPSec SA and/or shorewall sees are coming from the wrong "origin" ? > So my misunderstanding was that I somehow thought that these OpenVPN- > tunnel terminate on the firewall and therefore can fulfill the same SA that > I already defined for firewall to IPSec client-tunnels. > If I would be able to setup a bridged OpenVPN connection, then those SA''s > should match, because the packets from OpenVPN-clients look the same > as if they were coming from the internal zone "loc", right ? > So my last question is: > Is bridging with tap-devices the way to go ?I use the solution described above (bridged OpenVPN), it works quite well. In my case OpenVPN clients are in separate zone "ovpn" (defined in hosts as br0:$IP_RANGE), so I can regulate traffic from loc and ovpn to ipsec zones separately. Regards -- Artur ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Artur Uszyn''ski schrieb:> W dniu 2007-10-05 10:21, Philipp Rusch pisze: > >> Tom Eastep schrieb: >> >>> Philipp Rusch wrote: >>> >>> >>> >>>> my problem is that traffic is going to the wrong zone. >>>> When I try to access hosts in one of ipsec zones while I am sitting in an >>>> openvpn zone, my packets travel to "net" and hence don''t find their aim. >>>> >>>> >>>> >>> Your problem is that you don''t understand IPSEC. This is neither a >>> Shorewall problem nor is it a routing problem. As I said in my previous >>> message, you must configure IPSEC to encrypt the traffic -- then AND >>> ONLY THEN will it go to the right destination. >>> >>> -Tom >>> >>> >>> >> Tom, >> just for clarification: if I have a multihomed host sitting in a LAN >> with one >> arm and several openvpn clients on this same host, the packets that >> the IPSec SA and/or shorewall sees are coming from the wrong "origin" ? >> So my misunderstanding was that I somehow thought that these OpenVPN- >> tunnel terminate on the firewall and therefore can fulfill the same SA that >> I already defined for firewall to IPSec client-tunnels. >> If I would be able to setup a bridged OpenVPN connection, then those SA''s >> should match, because the packets from OpenVPN-clients look the same >> as if they were coming from the internal zone "loc", right ? >> So my last question is: >> Is bridging with tap-devices the way to go ? >> > > I use the solution described above (bridged OpenVPN), it works quite well. In my case OpenVPN clients are in separate zone "ovpn" (defined in hosts as br0:$IP_RANGE), so I can regulate traffic from loc and ovpn to ipsec zones separately. > > Regards > -- > Artur > >Hello Artur, great ! You have one of the new kernels ? I ask because of the limited bridge support ... Could you share your setup with me by private mail ? Regards from Germany, -- Mit freundlichen Grüßen, Philipp Rusch ------------------------------------------------------------------------ New Vision GmbH Neue Mitte 3 D-35415 Pohlheim, Germany Fon: +49 (0)6403 969 08 56 Fax: +49 (0)6403 969 08 57 Mobile : +49 (0)172 89 86 230 New Vision Logo <http://www.newvision-it.de> HRB 6415 Gießen Ust.-ID: DE 814 629 367 Web : www.newvision-it.de Mailto : Philipp.Rusch@newvision-it.de ------------------------------------------------------------------------ Diese E-Mail enthält vertrauliche und/oder rechtlich geschützteInformationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/