Need for a static route to routable IP behind IPSEC tunnel?
-
I have an IPSEC tunnel to a customer's site. The tunnel is established well (according to the ipsec log), but no traffic will route over the tunnel.
The net behind the tunnel on the customer's site is a routable net, so my question is:
Do I need a static route to tell my client machines which way to send the packets or does pfsense automagically route the packets destined to this routable ip through the tunnel (pfsense is the default gateway for my client machines)? If I need a static route, how do I address the tunnel in the static-routes page?
When the tunnel is established, shouldn't there be an entry in the Diagnostics->Route table?
Is there a way to monitor the amount of traffic which flows through the tunnel?
Thanks for any comments.
-
IPSEC doesn't have to do anything with routes. Only the local and remote subnet definition in the tunnel definition determines what's send through. In other words you have to include the routed subnet behind the tunnel in your remote subnet definition. Can you give me infomration on the local subnet at your end and the remote subnets (the routed one as well as the local one on the other end)? It's easier to describe how to set it up when knowing the subnets. You either can specify a big subnetmask at the remote end, containing both nets or if they can't be summed up easily, use parallel tunnels.
-
First: thanks for the quick answer.
Second:
My subnets are as follows:
Local subnet: 192.168.5.0/24 (although the customer only lets 4 of our IPs access his net)
Remote subnet: 195.60.xxx.0/24 (and we are only allowed to connect to one host: 195.60.xxx.52)
I had the tunnel established and working with a Netgear FVS318 before I switched to pfsense.
The customer uses a Checkpoint-1 FW (AFAIK).
Any chance that I can monitor whether there is traffic through the tunnel (no matter which direction)?
-
Where is the routed subnet? So it's basically a lan to lan connection?
That should just work usually. It's correct that the remote subnet is public IP-Space?You can check if the tunnel is established at status>ipsec or in the systemlogs at status>systemlogs, ipsec tab. For monitoring the traffic you can have a look at diagnostics>states, at the trafficgraph of the ipsec interface at status>trafficgraph or by viewing pftop from the shellmenu.
Are you sure the tunnel is actually up?
-
Ok, seems like I got you confused…here are more details:
My side:
pfsense with a public IP(WAN) doing NAT(LAN) for my local machines (192.168.5.0)
Customers side:
probably Checkpoint-1 FW with public IP, remote LAN behind that firewall has a public IP (195.60....)
The tunnel between my public IP and the customers public IP through the internet is established when I ping a host in the customers LAN. I can check that via status>systemlogs and status>ipsec.
But pinging hosts in the remote net is not allowed, so I get no answer, but it's the easiest way to establish the tunnel.
Now, I checked the Traffic graph of the IPSEC-interface (thanks for the hint, didn't see that at first). After the tunnel is established, there is no activity on the IPSEC-interface, no matter what I try to do (pinging, telnetting, etc.). Shouldn't there be at least OUT-traffic visible in the graph?
Ok, it gets even stranger: The RRD-Graphs really show outgoing IPSEC-Traffic, but the live traffic-graph doesn't.Good, that shows me that the traffic seems to go through the tunnel, but there seems to be no answer.
Hmm, eventually, the customers' host on the remote site, which I try to reach, is down. I have to check that now but I wanted to rule out all other things.Thanks for your help. I'll close the thread when I confirmed the problem on the customers' side.
-
Try a traceroute from your lan to the customers lan to see if the packets go through the tunnel. If you don't see the gateway of your ISP there it goes through the tunnel (diagnostics>states should show you that as well). Maybe your customer has his firewallrules not set up correctly and though the tunnel is established you are blocked at their end.