From owner-freebsd-net@freebsd.org Wed Mar 9 14:08:45 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A2CA9AC9D4E for ; Wed, 9 Mar 2016 14:08:45 +0000 (UTC) (envelope-from Vladimir.Terziev@bwinparty.com) Received: from mgate03.itsfogo.com (mgate03.itsfogo.com [195.72.134.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "*.itsfogo.com", Issuer "thawte SSL CA - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 42837D1C for ; Wed, 9 Mar 2016 14:08:44 +0000 (UTC) (envelope-from Vladimir.Terziev@bwinparty.com) From: Vladimir Terziev To: " " CC: Jan Bramkamp , freebsd-net Subject: Re: Source routing howto Thread-Topic: Source routing howto Thread-Index: AQHRee6Q0/m5RgFfW0ymY5bZBvj9cJ9Q6lwAgAAjcACAAAO2gA== Date: Wed, 9 Mar 2016 13:53:33 +0000 Message-ID: References: <56E00A06.20700@rlwinm.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [10.138.239.254] Content-Type: text/plain; charset="us-ascii" Content-ID: <139427116B75014288AF9850E370F1A7@bwinparty.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 14:08:45 -0000 Hi, would this rule to the trick for what you need ? ipfw add fwd Routed_B_IP ip from 10.10.10.0/24 to not 10.0.0.0/8 Regards, Vladimir On Mar 9, 2016, at 3:40 PM, wrote: >=20 > On Wed, 9 Mar 2016, Jan Bramkamp wrote: >> On 09/03/16 11:29, elof2@sentor.se wrote: >>> I've been searching the internet but can't find any good >>> documentation/examples on how to setup source routing in my FreeBSD. >>> What I want to do: >>> Let internet clients connect their OpenVPN to a FreeBSD box. The >>> client's internet traffic should be routed to a separate firewall >>> dedicated for all client networks (VPN and physical), where all clients >>> then leave the network. >>> The FreeBSD box has its own normal default gateway to speak with the >>> internet. >>> This route is needed in order to be able to keep the OpenVPN-traffic >>> flowing. >>> How do I source route the tunneled traffic, coming from e.g. 10.10.10.x >>> to the "client firewall"? >>> Are there any good examples out there? >>> Do I have to compile a custom kernel? >>> (the responses back from that firewall use a normal static route, >>> pointing 10.10.10.0/24 to the FreeBSD box) >>=20 >> Do I understand you correctly that you have a FreeBSD box acting as >>=20 >> * OpenVPN endpoint >> * router >> * and firewall >=20 > The FreeBSD box is an OpenVPN server. > Naturally it is also a router (forwarding enabled). > It has local firewall rules (using pf), but when I talk about a firewall = I mean a separate box (Juniper/Checkpoint/something). >=20 >> all in one system and you want use the OpenVPN tunnel as default route f= or your *other* hosts? >=20 > Heh, my description was pretty bad. >=20 > New try: > 100 clients around the world connect to an OpenVPN server called "SRV". > SRV has a default route, so incoming and outgoing VPN packets use interne= t connection A (router A). >=20 > So far everything is as normal it can be. A server, a default route and a= n internet connection. >=20 > Next, all the vpn clients' traffic is sucked into their VPN tunnels (no s= plit tunneling allowed). > The clients can reach internal servers. Good. > But when the clients surf the web, their traffic originates from SRV, usi= ng its default route towards the internet. >=20 > This works but is no longer what I want. >=20 > I now want the client traffic, aimed for the internet, to be routed elsew= here. In my case, "elsewhere" is a firewall with its own internet connectio= n (B). The firewall is equipped with extra functions/blades to inspect clie= nt traffic and have all the rules for client traffic. >=20 > So basically I want the remote VPN users' surf traffic to pass through fi= rewall B. >=20 > ( > In my example, the VPN clients will get IPs in the 10.10.10.0/24 range. >=20 > Firewall B only need to route 10.10.10.0/24 to SRV in order to forward th= e response surf traffic back to the VPN clients. > ) >=20 >=20 > So on SRV I need: > * traffic from SRV itself (openvpn responses, freebsd-update, mail, dns a= nd other stuff) to 'any' should be routed to router A. Currently my default= route. > * traffic with src net 10.10.10.0/24 to 'any' should be routed to B. >=20 > So two destinations for 'any'. Hence the need for source routing. >=20 > PS: traffic with src net 10.10.10.0/24 to internal nets, like 10.20.30.0/= 24, should still be routed normally and not be thrown onto router B. >=20 > Hope that description is better. >=20 >=20 >> In that case what you need is some kind of *policy* based routing. >> One way to go about it with more than one FIB (aka kernel routing table)= . The problem is that you have to decide on the routing table to use before= performing the route lookup. For packets forwarded through your FreeBSD ro= uter you have to select a non default FIB during input filtering e.g. >> # simple case >> ipfw add setfib 1 all from any to any in via $lan_if >> # complex case for multiple interfaces >> # ipfw table add >> ipfw table 1 add $lan_if1 1 >> ipfw table 1 add $lan_if2 2 >> ipfw table 1 add $lan_if3 2 >> ipfw table 1 add $lan_if3 2 >> # ... >> # lookup routing table number in a table >> ipfw add setfib tablearg all from any to any via table(1) >> For traffic generated by your FreeBSD router you can't use the firewall = to set the routing table because locally generated traffic only passes thro= ugh output filtering by which time the routing decision has already happend= . Instead you can set a processes default routing table with the setfib(1) = utility or use a setsockopt(2) with SO_SETFIB for each socket. Jails can al= so set default routing table for sockets created inside the jail. >=20 > Heh. Do you mind giving another example now with the above description of= the setup? > PS: i already use pf, not ipfw, on SRV. >=20 >=20 >> Remember that your DNS resolver can leak a lot of information as well if= it uses the default routing table. >=20 > Thanks for the heads-up. No, it uses an internal DNS. >=20 >=20 >> I would avoid policies based on IP addresses and prefer to define polici= es based on (pseudo-) interfaces e.g. route (and nat?) traffic from vlan123= through the VPN tunnel. >=20 > The only two things I have to play with here is: > * ip range 10.10.10.x > or > * tun0 >=20 > Using 'tun0' might not be possible if it has to exist when ipfw/pf load a= t boot, 'cause tun0 is not created until the openvpn service has started. >=20 > /Elof > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"