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, el...@sentor.se wrote: > Intrersting! > Unfortunetly I can't test right now. Will let you know. > > If I understand correctly, the 'ipfw fwd approach' don't use any FIBs, so it > should be applicable to the *outgoing* traffic. > > > > Regarding the FIBs: > > 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). > > Will release 10.3 or 11.0 have "options ROUTETABLES=2" in their GENERIC > kernel conf? Anyone knows? > > /Elof > > > On Wed, 9 Mar 2016, Vladimir Terziev wrote: > >> 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, <el...@sentor.se> >> wrote: >> >>> >>> On Wed, 9 Mar 2016, Jan Bramkamp wrote: >>>> On 09/03/16 11:29, el...@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) >>>> >>>> Do I understand you correctly that you have a FreeBSD box acting as >>>> >>>> * OpenVPN endpoint >>>> * router >>>> * and firewall >>> >>> 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). >>> >>>> all in one system and you want use the OpenVPN tunnel as default route for >>>> your *other* hosts? >>> >>> Heh, my description was pretty bad. >>> >>> 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 internet >>> connection A (router A). >>> >>> So far everything is as normal it can be. A server, a default route and an >>> internet connection. >>> >>> 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, using >>> its default route towards the internet. >>> >>> This works but is no longer what I want. >>> >>> I now want the client traffic, aimed for the internet, to be routed >>> elsewhere. In my case, "elsewhere" is a firewall with its own internet >>> connection (B). The firewall is equipped with extra functions/blades to >>> inspect client traffic and have all the rules for client traffic. >>> >>> So basically I want the remote VPN users' surf traffic to pass through >>> firewall B. >>> >>> ( >>> In my example, the VPN clients will get IPs in the 10.10.10.0/24 range. >>> >>> 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. >>> ) >>> >>> >>> 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 default >>> route. >>> * traffic with src net 10.10.10.0/24 to 'any' should be routed to B. >>> >>> So two destinations for 'any'. Hence the need for source routing. >>> >>> 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. >>> >>> Hope that description is better. >>> >>> >>>> 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 >>>> 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 firewall to >>>> set the routing table because locally generated traffic only passes >>>> through 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 also set default routing table for sockets created inside the >>>> jail. >>> >>> Heh. Do you mind giving another example now with the above description of >>> the setup? >>> PS: i already use pf, not ipfw, on SRV. >>> >>> >>>> Remember that your DNS resolver can leak a lot of information as well if >>>> it uses the default routing table. >>> >>> Thanks for the heads-up. No, it uses an internal DNS. >>> >>> >>>> I would avoid policies based on IP addresses and prefer to define policies >>>> based on (pseudo-) interfaces e.g. route (and nat?) traffic from vlan123 >>>> through the VPN tunnel. >>> >>> The only two things I have to play with here is: >>> * ip range 10.10.10.x >>> or >>> * tun0 >>> >>> 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. >>> >>> /Elof >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" >> _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
