Date: Wed, 9 Mar 2016 14:41:45 +0000 From: Vladimir Terziev <Vladimir.Terziev@bwinparty.com> To: "elof2@sentor.se" <elof2@sentor.se> Cc: freebsd-net <freebsd-net@freebsd.org>, Jan Bramkamp <crest@rlwinm.de> Subject: Re: Source routing howto Message-ID: <D335FEE9-5C52-403A-94B5-81B67A248186@bwinparty.com> In-Reply-To: <alpine.BSF.2.00.1603091511520.3214@farmermaggot.shire.sentor.se> References: <alpine.BSF.2.00.1603091119130.3214@farmermaggot.shire.sentor.se> <56E00A06.20700@rlwinm.de> <alpine.BSF.2.00.1603091336380.3214@farmermaggot.shire.sentor.se> <CF69906D-E2A1-44D0-B614-B2B55B87FC3F@bwinparty.com> <alpine.BSF.2.00.1603091511520.3214@farmermaggot.shire.sentor.se>
next in thread | previous in thread | raw e-mail | index | archive | help
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, <elof2@sentor.se> >> 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 <table_number> add <interface> <fib_number> >>>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D335FEE9-5C52-403A-94B5-81B67A248186>