Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    I'm trying to use pfSense in an unusual network and I am having IPsec problems

    Scheduled Pinned Locked Moved IPsec
    1 Posts 1 Posters 716 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • F
      fx2000
      last edited by

      I've been trying to move our test environment from physical servers to cloud-hosted VMs. I haven't had a problem with the software itself, that part went pretty well, but I am having a ton of problems establishing a VPN connection with our provider's test environment. Initially we tried using Vmware vCNS (the solution provided by our host), but we ran into a major roadblock, our provider has assigned us a specific IP range that is different from the one our LAN interfaces are assigned by the hosting company (it's a public cloud, so I can't do my own IP infrastructure), and the hosting company's vCNS implementation does not support natting for whatever reason.

      Anyway, I had this idea of deploying a new VM running pfSense to use as our VPN endpoint and route all the traffic to and from our provider through it.

      You can see what it looks like in this diagram:

      http://i.imgur.com/GUfW0GZ.jpg

      I have three VMs, each one has a WAN network interface with a public IP address and a LAN interface with a private IP address in the 10.34.157.0/8 range. Two of these VMs (test1 and test2) are running our test environment, the third one (pfSense) is running pfSense 2.1.5-RELEASE  (amd64). I have our test software and pfSense running correctly, I created static routes on all VMs so that traffic directed to the 10.34.157.0/8 range is sent through the LAN interface, which uses 10.34.157.17 as a gateway (this is assigned by our hosting company) and I have created another static route in test2 that makes sure all traffic to the Provider's IP address is routed through the pfSense VM (10.34.157.22).

      I have configured the VPN settings in IPsec according to the information given to me by our provider, created a 1:1 NAT in those settings that will turn test2's IP address from 10.34.157.20 to 10.254.126.9 (an IP address in the range assigned to us by our Provider) and created firewall rules to allow traffic to go through on the NATed IP and port, but the tunnel is always marked with a yellow Error icon in Status:IPSec and I can see this in the log:

      Dec 10 18:52:30 racoon: INFO: caught signal 15 
      Dec 10 18:52:30 racoon: INFO: racoon process 34538 shutdown 
      Dec 10 18:52:35 racoon: INFO: @(#)ipsec-tools 0.8.1 (http://ipsec-tools.sourceforge.net) 
      Dec 10 18:52:35 racoon: INFO: @(#)This product linked OpenSSL 1.0.1i 6 Aug 2014 (http://www.openssl.org/) 
      Dec 10 18:52:35 racoon: INFO: Reading configuration from "/var/etc/ipsec/racoon.conf" 
      Dec 10 18:52:35 racoon: [Self]: INFO: PFSENSE.PUBLIC.IP[4500] used for NAT-T 
      Dec 10 18:52:35 racoon: [Self]: INFO: PFSENSE.PUBLIC.IP[4500] used as isakmp port (fd=14) 
      Dec 10 18:52:35 racoon: [Self]: INFO: PFSENSE.PUBLIC.IP[500] used for NAT-T 
      Dec 10 18:52:35 racoon: [Self]: INFO: PFSENSE.PUBLIC.IP[500] used as isakmp port (fd=15) 
      Dec 10 18:52:35 racoon: INFO: unsupported PF_KEY message REGISTER 
      Dec 10 18:52:35 racoon: ERROR: such policy already exists. anyway replace it: 10.34.157.22/32[0] 10.34.157.0/27[0] proto=any dir=out 
      Dec 10 18:52:35 racoon: ERROR: such policy already exists. anyway replace it: 10.34.157.0/27[0] 10.34.157.22/32[0] proto=any dir=in 
      Dec 10 18:52:35 racoon: ERROR: such policy already exists. anyway replace it: 10.34.157.20/32[0] PROVIDERS.IP/32[0] proto=any dir=out 
      Dec 10 18:52:35 racoon: ERROR: such policy already exists. anyway replace it: PROVIDERS.IP/32[0] 10.254.126.9/32[0] proto=any dir=in

      It seems like it isn't even trying to establish the tunnel, even though I'm generating traffic from 10.34.157.20 to the Provider's IP address. Can you think of what I might be doing wrong? is there any reason to think my idea shouldn't work? the hosting company isn't being of much help, since pfSense isn't supported by them, but they didn't seem to think this was an unworkable solution to our problem.

      1 Reply Last reply Reply Quote 0
      • First post
        Last post
      Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.