Cisco ASA (VPN) behind pfSense?



  • Hi there.

    We are currently using CISCO ASA 5510 for VPN and DD-WRT for routing - in parallel. Meaning the router has 111.111.111.221 WAN IP and ASA has 111.111.111.222 adress. I am not happy with having two devices in parallel mode because I have no control of QoS whatsoever. My idea was either to have the ASA handle everything or to replace ddwrt for pfsense and have pfsense handle everything. The problem is that ASA does not do routing well and pfSense doesen't have VPN as comfortable as ASA does (no clientless mode).

    So my intention would be to put ASA behind pfSense. I've read some topics about it being a bad idea because of complexity, but I really don't mind using ASA as VPN only. Ao pfSense would be the main router, handling DMZ, WAN and LAN, I would probably put ASA in DMZ (?). I am still not sure if there would be some issues regarding the fact I have a site-to-site VPN on my ASA (routing issues and setup), but my main concern is pfSense. Can you advise me on what setup/config to pursue? I would like for external VPN users not to notice any change, so they would be using the same VPN public IP to connect, I would then forward/redirect/transparent/… the IP to ASA in DMZ and have it handle VPN sessions. Am I thinking right or am I missing something? Does such VPN passthrough work well in pfSense?

    TIA



  • If you put the VPN server device (Cisco ASA) in the ordinary LAN behind pfSense then you get some asymmetric routing that you have to work around somehow (or enable sloppy states for related rules). e.g.
    Main Office LAN 10.20.1.0/24
    pfSense 10.20.1.1
    Cisco 10.20.1.2

    Branch office 10.21.1.0/24

    Site-to-site VPN tunnel 10.22.1.0/24

    pfSense has a static route to 10.21.1.0/24 via 10.20.1.2

    When a packet is sent to a device in Main Office LAN from Branch office, Cisco delivers it directly on Main Office LAN. But the device replies to pfSense (its default gateway) and pfSense sends it on to Cisco and Branch office. pfSense only sees packets in 1 direction.

    You can:
    a) Add a route to every device in Main Office LAN that talks to Branch office, specifying the route via Cisco. That works if you have a limited set of servers that are accessed across the VPN; or
    b) Put Cisco in a separate subnet and (NIC|VLAN) behind pfSense. Then there are no Main Office devices in the Cisco LAN to get confused about having 2 gateways to different places (pfSense to internet, Cisco to intranet). Main Office LAN devices would always talk to pfSense as the gateway, and pfSense routes to Cisco when the destination is across a VPN link (for site-to-site and road warrior).

    For incoming VPN connects, forward the port/s from the pfSense WAN(s) to Cisco.

    It is all possible, but of course, being somewhat biased, many on this forum including me would say why not have the VPN endpoints on pfSense and take the Cisco out of the equation.



  • @phil.davis:

    If you put the VPN server device (Cisco ASA) in the ordinary LAN behind pfSense then you get some asymmetric routing that you have to work around somehow (or enable sloppy states for related rules). e.g.
    Main Office LAN 10.20.1.0/24
    pfSense 10.20.1.1
    Cisco 10.20.1.2

    Branch office 10.21.1.0/24

    Site-to-site VPN tunnel 10.22.1.0/24

    pfSense has a static route to 10.21.1.0/24 via 10.20.1.2

    When a packet is sent to a device in Main Office LAN from Branch office, Cisco delivers it directly on Main Office LAN. But the device replies to pfSense (its default gateway) and pfSense sends it on to Cisco and Branch office. pfSense only sees packets in 1 direction.

    You can:
    a) Add a route to every device in Main Office LAN that talks to Branch office, specifying the route via Cisco. That works if you have a limited set of servers that are accessed across the VPN; or
    b) Put Cisco in a separate subnet and (NIC|VLAN) behind pfSense. Then there are no Main Office devices in the Cisco LAN to get confused about having 2 gateways to different places (pfSense to internet, Cisco to intranet). Main Office LAN devices would always talk to pfSense as the gateway, and pfSense routes to Cisco when the destination is across a VPN link (for site-to-site and road warrior).

    For incoming VPN connects, forward the port/s from the pfSense WAN(s) to Cisco.

    It is all possible, but of course, being somewhat biased, many on this forum including me would say why not have the VPN endpoints on pfSense and take the Cisco out of the equation.

    Hey Phil, thanx for helping me out!

    Having "parallel" configuration (ASA and router on the same level) resulted in having some servers using modified routes that use ASA as the gateway. I can live with that. The configuration now is working but I would prefer to have ASA behind pfSense because I would have at least some more control by having single point of entry/exit. I am not a big fan of Ciscos filosophy, am more aligned with pfSense, but users (and me) like the "clientless" VPN, users just open a URL and authenticate themselves - they're in VPN. Also, I wouldn't like to touch the existing site-to-site configuration since it's working fine. PfSense offers better routing features, but I like the Cisco VPN stuff.

    So, if I go for a), how do I need to configure the pfSense? Are we talking about 1:1 NAT, Trasnparent mode, bridge… are we talking about assigning virtual IPs to pfSense and than forwarding the traffic to ASA which is running with private IP? Or do I get to make the ASA use public IP? Instead of forwarding only specific traffic to ASA, I can forward all traffic to the specific public IP the ASA is using, right?
    I just need some keyword so I can do some google digging, and the information if such configuration makes sense.

    I also need to have some reasonable VoIP QoS in there, hope pfSense will adequate for that.

    TIA



  • I don't think you will need any fancy stuff. The pfSense could use the public IP that the ASA now uses. Whatever ports the ASA VPN software is listening on, just forward those from pfSense WAN into the ASA private IP address. (You could forward all ports (1:1) - but that limits you in future if you want to forward port 80 to a web server or…).

    The ASA will need to know that the internal private hop back to the pfSense is a route to whatever LAN and any other subnets pfSense has connected to it. pfSense needs to similarly be told what subnets are available routed through the ASA. Add pass rules appropriately to let the traffic through and it should go.

    I am not a VoIP expert - we are just getting fast enough internet here in Nepal to now start looking at it, so I will be on the learning end of that soon.



  • Dumping the ASA and using pfsense for firewall, routing and VPN would simplify things for you extremely.



  • @kejianshi:

    Dumping the ASA and using pfsense for firewall, routing and VPN would simplify things for you extremely.

    I've put the ASA behind pfSense 1:1 (with dedicated public IP) and it seems to be working perfectly (am still testing). I don't think the configuration is complicated or flawed, please correct me if I am wrong. I am big fan of pfSense but I see no point in repeating "kick the ASA" without providing any alternatives. I need the users to be able to logon to any computer worldwide (Java being a requirement) and establish a VPN Session without admin permissions, without installing any aditional software… just enter URL in a browser, logon and use the VPN. Can pfSense provide such user-friendly VPN functionality? If yes, please forward me to additional information. If not, please stop repeating I should use pfSense for something pfSense cannot provide, it's not helpfull. I would be more then happy to have a single device if I could. I think the ASA behinf pfSense provides me with besto of ASA and best of pfSense, what's the big issue here? Why is one aditional appliance considered such a complication? It is still a firm firewall on it and I don't consider Cisco devices to be of any additional risk? I have no additional rules on ASA, it provides only VPN sessions, so I guess there is no risk there.



  • I like what you are doing.  Seems to work perfectly.  I'd stick with it if its not giving you issues.  ;)

    If you have multiple public IPs and 1:1 NAT, of course its not an issue.  (probably)

    P.S.  I didn't repeat anything.  I said once that it might simplify things for you.

    Touchy touchy…

    Anyway, I'm glad its working for you.  I'm not really sure why it was giving you issues to begin with?  That WebVPN stuff isn't ACTUALLY VPN.
    In the past, I've used a FreeNX server to do pretty much the same thing.  Also, ThinVNC.  There was never any competition/problems with the actual VPN that ran on the same public IP and subnet.

    Prerequisites for ASA:

    Requirements

    Ensure that you meet these requirements before you attempt this configuration:

    Client-SSL enabled browser, for example, Internet Explorer, Netscape, and Mozilla

    ASA with Version 7.1 or higher

    TCP port 443, which must not be blocked along the path from the client to the ASA

    With the exception of wanting port 443 all to its self, I see no port conflicts with openvpn (assuming you can run pfsense on another port)


Log in to reply