WAN static IP - IPSec no traffic (Tunnel is up and i have IPSec rules)
since a long time now, i had to setup a IPSec VPN between a Cisco ASA and a pfSense (newest RC1 embedded for Alix). This is not my first try … i have several working Tunnels (also many with pfSense at the other end) working like a charm. But all pfSense installations are connected via Dialup PPPoE. This is the first time i tried this to setup with static IP. Here is, what happened:
I use a working base config with very essential settings. I restored this config in my Alix Box and modified some things: Bridged VR1 and VR2 (both LAN Ports), Added a Gateway as a defaultGW, switched from PPPoE to Static using this Gateway and changed LAN IP ...
Surfing works great. Logs look fine. Bridge is working. All seems to be OK.
After configuring the IPSec (using a PSK) a Ping triggers the IPSec negotiation. All is fine. Tunnel is shown me as up in dashboard and Cisco ASDM. Logs looking great - also on Cisco side. My only Problem is, that nothing goes through the tunnel! Of course i'd set up a Rule under IPSec Tab which is allowing everything. Ok, it is not realy nothing ... sometimes ... for a few seconds ... traffic passes (without changing anything). At the moment i cant figure out why. But these times are very rare. Most of the time the tunnel shows up but no traffic passes.
After trying different things which not help i switched back to pfSense factory defaults and configured the whole thing from scratch. I just configured essential things (WAN / LAN IP / IPSec) and let the rest as it is (i didn't configured a bridge and so on ...)! Same - nothing helps. And also nothing in firewall logs, which could tell me where are the packets gone. An update to the latest snapshot didn't fix anything.
I have a small Testnet with public IPs, where i'm testing this. I tried now to perform the same setup with a actual m0n0wall to eliminate all things outside of my alix/pfSense box. It costs me only a few minutes to get the whole thing running. I used same WAN IPs and LAN IPs and IPSec settings. IPSec is going up (as also with pfSense) but traffic is passing the tunnel.
Does anybody have a clue whats going wrong? Help would be appreciated ... thx! If i should post more information, tell me please what to post ...
I tested it now also on a PC installed with actual snapshots Live CD instead Alix board with embedded image … same issue. Will try now 1.2.3 Release and report back.
hmm … tried also on 1.2.3 ... and it works immediately :-\
Normally i would tend to say: It's probably my fault. But at the moment i'm not sure. Finally i tried now many different platforms (1.2.3 / 2.0 RC1 / m0n0 1.33) on either PC and Alix platform. All is working - except 2.0 RC1. On the other Hand i cannot believe, that other users in same environments don't have the same issue ... that i'm the one&only ... cause this should be a very common scenario.
Did i forgot someting ... something what's now to configure in 2.0 and was not needed before?
Otherwise i have many 2.0 RC1 connected with PPPoE instead of static with working IPSec setups ... may be it's just a bug?
Don't know ... maybe someone can give a hint!
Here's some more information: I tried now several times with 2.0 RC1, Tunnel is up, but no Traffic going trough. If i try it with other platform like 1.2.3 or m0n0 it works at first attempt! pfSense is connected without modem directly to ethernet using WAN IP like 126.96.36.199. The IP configuration of the provider is as follows:
IP Net: 188.8.131.52 /28
Subnet Mask: 255.255.255.240
Standard GW: 184.108.40.206
Usable IPs: 220.127.116.11-222
DNS Server1: 18.104.22.168
DNS Server2: 22.214.171.124
This is what i did:
reset pfSense 2.0 RC1 to factory defaults
Using the wizard …
... i set the WAN IP to 126.96.36.199 /28
... and the GW IP to 188.8.131.52
... the LAN IP to 192.168.255.254 /24
... the DNS Servers to 184.108.40.206 and 220.127.116.11
After initial Wizard Setup i did this:
Setup a rule allowing all traffic und IPSec Tab in the GUI
Setup IPSec phase 1 with 18.104.22.168 as remote IPSec GW
Setup IPSec phase 2
Then i pinged to a destination in the IPSec remote subnet. The tunnel comes up. Both sides of the Tunnel shows up. No errors in log ...
... and no traffic passes!
Both endpoints are under my control. And as already said ... if i try it with other than 2.0 RC1 (1.2.3 / m0n0 etc.) it works at 1. attempt. Any Idea whats going wrong?
I'm assuming traffic fails in both directions? If you log passed traffic on the pfsense, and log on to a machine at the m0n0wall(remote) site, does traffic make it through to pfsense?
Does the SAD and SPD look correct under Status > IPSEC in 2.0?
Yes … its failing in both directions!
But, as i wrote, sometimes ... for a very short time ... traffic passes the tunnel! I think it has something to do with, when i just ping the public wan ip's vice versa, and try then to ping inside the tunnel, and again and again ... sometime its possible in both directions. This tells me that there could not be a mismatch within the rules, otherwise they would block at any time. And i allowed explicit all traffic at IPSec tab in the gui.
Nor Cisco or pfSense has logged any issues. Tunnels up in logs and in gui of pfSense and ASA.
I definitely trust you've set up the ipsec tunnel properly since you've set up all the others correctly.
Just curious, have you tried without encryption?
I made a other test:
I restored a working config (2.0 RC1) from a customer connected via PPPoE having a working IPSec Tunnel. Then i'd setup a Gateway as DefaultGW, switched from WAN PPPoE to WAN Static IP using the Gateway. Changed the LAN IP to my Testnet and the Phase 1 entry from Certs to PSK (PSK = 1234Test) and let the rules unchanged (Allow all incoming IPSec).
Same same: Tunnel comes up immediately … but passes NO traffic. This must be some kind of bug!
At the moment i have only the alternative to ship an old 1.2.3 to my customer, which is in a foreign country. I hope i can update it at a later time remotely, when 2.0 is released and the issue is solved. But of course i'm interested i a solution to that issue ...