From owner-freebsd-net@freebsd.org Wed Mar 9 14:41:48 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 D8766AC9B81 for ; Wed, 9 Mar 2016 14:41:48 +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 79CD33B5 for ; Wed, 9 Mar 2016 14:41:47 +0000 (UTC) (envelope-from Vladimir.Terziev@bwinparty.com) From: Vladimir Terziev To: "elof2@sentor.se" CC: freebsd-net , Jan Bramkamp Subject: Re: Source routing howto Thread-Topic: Source routing howto Thread-Index: AQHRee6Q0/m5RgFfW0ymY5bZBvj9cJ9Q6lwAgAAjcACAAAO2gIAACTAAgAAERwA= Date: Wed, 9 Mar 2016 14:41:45 +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: 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:41:48 -0000 Don't forget, your router B should return back to router A (the FreeBSD box= ) all packets destinated to 10.10.10.0/24 . Regards, Vladimir On Mar 9, 2016, at 4:26 PM, elof2@sentor.se wrote: > Intrersting! > Unfortunetly I can't test right now. Will let you know. >=20 > If I understand correctly, the 'ipfw fwd approach' don't use any FIBs, so= it should be applicable to the *outgoing* traffic. >=20 >=20 >=20 > Regarding the FIBs: >=20 > In FreeBSD 10.1 RELEASE, no extra FIBs can be added since that kernel is = compiled without support for it. :-( > I'm hesitant to break binary compability (I use freebsd-update). >=20 > Will release 10.3 or 11.0 have "options ROUTETABLES=3D2" in their GENERIC= kernel conf? Anyone knows? >=20 > /Elof >=20 >=20 > On Wed, 9 Mar 2016, Vladimir Terziev wrote: >=20 >> Hi, >>=20 >> would this rule to the trick for what you need ? >>=20 >> ipfw add fwd Routed_B_IP ip from 10.10.10.0/24 to not 10.0.0.0/8 >>=20 >>=20 >> Regards, >>=20 >> Vladimir >>=20 >>=20 >> On Mar 9, 2016, at 3:40 PM, >> wrote: >>=20 >>>=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 clien= ts >>>>> 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 firewal= l I mean a separate box (Juniper/Checkpoint/something). >>>=20 >>>> all in one system and you want use the OpenVPN tunnel as default route= for 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 inter= net connection A (router A). >>>=20 >>> So far everything is as normal it can be. A server, a default route and= an internet connection. >>>=20 >>> Next, all the vpn clients' traffic is sucked into their VPN tunnels (no= split tunneling allowed). >>> The clients can reach internal servers. Good. >>> But when the clients surf the web, their traffic originates from SRV, u= sing 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 els= ewhere. In my case, "elsewhere" is a firewall with its own internet connect= ion (B). The firewall is equipped with extra functions/blades to inspect cl= ient traffic and have all the rules for client traffic. >>>=20 >>> So basically I want the remote VPN users' surf traffic to pass through = firewall 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 = the 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= and other stuff) to 'any' should be routed to router A. Currently my defau= lt 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 tabl= e). The problem is that you have to decide on the routing table to use befo= re performing the route lookup. For packets forwarded through your FreeBSD = router 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 firewal= l to set the routing table because locally generated traffic only passes th= rough output filtering by which time the routing decision has already happe= nd. 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 = also 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 poli= cies based on (pseudo-) interfaces e.g. route (and nat?) traffic from vlan1= 23 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= at 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" >>=20 >> _______________________________________________ >> 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" >>=20