You know you have to assign an interface to the OpenVPN client instance in order to NAT on it right?  Search on OpenVPN Assigned Interface.

No. Not that I've ever seen anyhow.

Respectfully disagreeing with Derelict, I wouldn't use an alias unless the VIP was in a different subnet. I would use a proxy arp for a simple setup.

@Taras: So, this works with pfSenses: 1. pfSense in head office (HO) with 2 ISPs. L2TP server listens on LAN IP (patch here https://redmine.pfsense.org/issues/4830), RDR rules for udp/1701 from WAN1 to LAN and from WAN2 to LAN. 2. pfSense in branch office (BO) with 1 ISP. Two L2TP clients: first one connects to WAN1 IP of HO, another one connects to WAN2 IP of BO. Each tunnel works fine. 3. OSPF on top of it. Two problems: mpd5 in pfSense choses random source port while connecting to L2TP, but in mikrotik (RouterOS) each L2TP client strictly uses 1701 as source port. It seems like mpd5 can't understand that he is dealing with two clients connecting from same port/IP. It's much easier to have two (or more) L2TP servers to setup different OSPF costs for interfaces (i.e. first L2TP server for "main" tunnels and second L2TP server for "failover" ones). I want to see ability to run multiple L2TP servers on pfSense, it should solve both problems. P.S. Mikrotik routers is functional and cheap. Another desire to be able to run pfSense on top of such cheap HW )))))) (1) seems to be solved in mikrotik: Mark L2TP packets flying from BO's mikrotik to HO pfSense's WAN1 IP: [admin@MikroTik] > /ip firewall mangle print Flags: X - disabled, I - invalid, D - dynamic 0    chain=output action=mark-packet new-packet-mark=l2tp passthrough=yes protocol=udp dst-address= <ho pfsense's="" wan1="" ip="">dst-port=1701 log=no log-prefix=""</ho> Change source port in L2TP packets: [admin@MikroTik] > /ip firewall nat print  Flags: X - disabled, I - invalid, D - dynamic 0    chain=srcnat action=src-nat to-ports=1702 protocol=udp packet-mark=l2tp log=no 1    ;;; default configuration       chain=srcnat action=masquerade out-interface=ether1-gateway log=no log-prefix=""

The range of addresses that are accessible via the tunnel are configured in the VPN configuration already.  They include the range I am trying to access. The one router at the colo is the end goal, but for the next 6-8 weeks I have to live with the current configuration. Thanks for your help.

@tobiascapin: This can be interesting… but can I choose (for some rules) to force a specific gw? For example I need to route the smtp traffic to my smtp provider by a specific interface, not from both. I do this because I have one WAN interface with static IPs and the other is DHCP.  SpamHAUS blocks SMTP from my ISP's DHCP block (for obvious reasons), so I need to force traffic from that server out the one interface.  This is the rule I have in place to do that (see attached). The server is on the LAN which has a different default gateway, and WAN2GW has the static assignment.  So I created a rule that says all outgoing traffic must use that gateway.  Works like a charm.  

Your problem is more than just rules, it's interface addresses and subnets.

here there are: [image: Gateway-Groups.PNG?dl=0]

I can help you with a MC7700 flashed to DIP mode if you don't mind a used module.. Send PM if interested.

I don't think you will have ANY joy if you tried to BGP advertise a /29 anyway. Sounds like you're talking about routed subnets.  That would be four interfaces.  The two ISP interfaces (/30s ?) and the two /29s. As stated, you can do this with one pfSense.  You would need to policy-route out the proper WAN port or you could NAT out either. Note that there is nothing stopping you from using NAT for outbound traffic from one provider's IP addresses to the other's in a failover, emergency situation.  You could: ISP 1 addresses out ISP 1's WAN - No NAT ISP 1 addresses out ISP 2's WAN - NAT And vice versa.  Nothing you can do about inbound connections other than change DNS.

policy based routing, service based routing or session based routing would be doing the job more or less better as I see it right.

yup if they route that segment to your other IP, then you could put whatever you want behind it broken up how ever you want to break it up

My pfSense version is 2.0.1. I consider to @heper to update pfSense to the version 2.2.3 to be clear and on the save side that this is not a bug, that is solved out since month or days! When I run speedtest.net I only get 3-4 Mbps. Ok then please also accept that the pfSense must be filtering out by this rule all other traffic and this might be using time, on not so actual hardware. I changed the rule to "any" protokoll, now I get 70 -100 Mbps. In this case nothing must be filtered out and all traffic can be flow. Hope someone can explain me this behavior. Its not really strange to understand that pfSense like all other firewalls gets even slower and slower if on the other side the firewall get more and more to do! And yes pfSense is running on the oldest and cheapest hardware you will be able to pull out of the dump, without no problems I mean, but then also please accept that the performance often is not the same as other peoples are telling around from their pfSense firewall. You pay what you get for. Or it could be in some rarely cases that the pfSense firewall could, should or must be tuned at the one or other corner to run flawless and smooth.

Try out using "policy based routing" to manage the internal traffic. The both routers are often able to work in the so called "bridged modus" only acting as a pure modem (figure 1)  ;) If not, they can be the front line where the Web Server is standing behind inside a so called "dual homed DMZ" (figure 2)  ::) To reach form the outside the Web Server it is even necessary to open and forward ports, whatever then in normal the web server will not be placed inside the LAN, that you have to open ports directly to the LAN, there for a DMZ will be created today thats the normal and also safe way. [image: tomli.jpg] [image: tomli.jpg_thumb]

vpn config: "Don't pull routes" interfaces –> assign  (assign an interface to ovpnc_x) enable new interface (IPv4/6 Configuration Type: none) restart openvpn you should now have a new gateway (one for the openvpn interface) adjust your LAN firewall rules todo what you want todo ( advanced features: gateways)

Dude draw up this question You state 10.10.1.0/24, called Network A Then you state For all the osts in Network A the default gateway is 10.10.0.1 – How and the F does that work?? Then I set a route on that gateway to Network B: 10.10.0.2 (which is the firewall protecting Network B's interface in the Network A) Where are you setting this??  So have down stream networks?  If you host route your more than likely going to have asymmetric routing..  If you have these networks both connected to pfsense - how do you think you would get to the other network without routing through that networks gateway? If you trying to cut out a hop by create host routes this is problems waiting to happen!!  And extra working making sure hosts have routes.. If you have an actual valid question - please draw up what your asking about and happy to discuss with you why asymmetrical routing is BAD idea…  If you have downstream networks, ie another router/firewall in your network with networks behind you need to get to the best solution is a transit network. As to why so many replies dok - is you keep posting ;)

so basically the static routes get overwritten by bgp ? i've never used openbgpd myself … i did use openospf in the past, but have since moved on to the much more feature-rich 'quagga-ospf' todo my dynamic routing. what i did find after some googling, you can find below (no clue if the package GUI allows you to insert manual entries to the config) Filters: But not so fast probably we should setup some filters so that only valid routes are accepted by bgpd. This sounds complex but luckily the default /etc/bgpd.conf file includes already a good default filter set. # filter out prefixes longer than 24 or shorter than 8 bits deny from any allow from any prefixlen 8 - 24 # do not accept a default route deny from any prefix 0.0.0.0/0 # filter bogus networks deny from any prefix 10.0.0.0/8 prefixlen >= 8 deny from any prefix 172.16.0.0/12 prefixlen >= 12 deny from any prefix 192.168.0.0/16 prefixlen >= 16 deny from any prefix 169.254.0.0/16 prefixlen >= 16 deny from any prefix 192.0.2.0/24 prefixlen >= 24 deny from any prefix 224.0.0.0/4 prefixlen >= 4 deny from any prefix 240.0.0.0/4 prefixlen >= 4 For each update message processed by the filter, the filter rules are evaluated in sequential order, from first to last. The last matching allow or deny rule decides what action is taken. The following rule-set allows only prefixes with a prefix length between a /8 and /24. Then the rule-set explicitly denies the default route plus other non routeable networks like those defined in RFC 1918. The example is using RFC 1918 addresses so it will not correctly work out of the box because of the filters but that's on purpose.