VPN ok, but no traffic on it…

sap68

Hi,

I try to connect my Pfsense 1.2.3 (on alix 2D) to a Netasq 120.

The tunnel goes UP and running (and I add the passall rule on IPSec interface on either netasq and pfsense), but I can't reach the remote subnet.

I'm shure the endpoind, remote subnet, pre-shared key etc, it's correct (in fact the tunnel is UP!).

I dont' know what happen…

PS.
Pfsense it's connected in internet trough PPPoE on Wan interface (but obtain a static IP).

Can you help me?

Thanks...

psylo

Well… The best way to troubleshoot that is to use tcpdump to "dump" the packet on both firewall.

I suggest you to:
1. Launch a continuous ping.
2. dump packet on enc0 interfaces (both sides). The enc0 interface is the IPsec interface.

If you don't see icmp packet on one of these interface, you have a problem with your tunnel.
If you can see icmp packet (as I understand, you'll only see "icmp request") on both sides, then dump packets on remote LAN interface (if the target lays on this interface).

If you don't see any packet on this interface, it means you have a problem with filtering. If you see ICMP "echo request" but no ICMP "echo reply", you have a routing problem.

Here is an example of tcpdump command:
tcpdump -i enc0 icmp -> it will show only icmp packet on interface enc0

Replace enc0 by the interface name. You can find the name via:

ifconfig on pfSense.
ifinfo on Netasq.

Hope this helps.

sap68

@psylo:

Well… The best way to troubleshoot that is to use tcpdump to "dump" the packet on both firewall.

I suggest you to:
1. Launch a continuous ping.
2. dump packet on enc0 interfaces (both sides). The enc0 interface is the IPsec interface.

If you don't see icmp packet on one of these interface, you have a problem with your tunnel.
If you can see icmp packet (as I understand, you'll only see "icmp request") on both sides, then dump packets on remote LAN interface (if the target lays on this interface).

If you don't see any packet on this interface, it means you have a problem with filtering. If you see ICMP "echo request" but no ICMP "echo reply", you have a routing problem.

Here is an example of tcpdump command:
tcpdump -i enc0 icmp -> it will show only icmp packet on interface enc0

Replace enc0 by the interface name. You can find the name via:

ifconfig on pfSense.

ifinfo on Netasq.

Hope this helps.

First of all: Thanks a lot.

I Always try to dump an icmp packet on both interface, I see packet coming to the first interface but not on remote side.
On remote interface it's the same.

At this moment i'm out of office and I can't check and post anything, i'm convinced it's a routing problem or something closer.

Thanks again, tomorrow I can give more detail.

psylo

Hello,

What do you call remote interface?

Can you make a quick draw explaining where you see icmp packet and where you don't?

sap68

@psylo:

Hello,

What do you call remote interface?

Can you make a quick draw explaining where you see icmp packet and where you don't?

It's a simple point-to-point VPN

Office1 LAN: 192.168.50.0/24 -> pfsense (192.168.50.1/publIP)
Office2 LAN: 172.16.120.0/24 -> netasq (172.16.120.1/publIP)

The configuration of tunnel I'm sure it's ok, because the tunnel goes ON (see image attached):

Anyway, I was wrong about ping: when from my LAN (192.168.50.0) try to ping remote private ip of netasq (172.16.120.1), the packet is recognised by netasq, in fact if I dump the IPSec interface this is the resul of my ping:


U120XA0A0804150>tcpdump -ni enc0
tcpdump: WARNING: enc0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enc0, link-type ENC (OpenBSD encapsulated IP), capture size 96 bytes
09:49:12.598323 (authentic,confidential): SPI 0x08641654: IP 192.168.50.198 > 172.16.120.1: ICMP echo request, id 17957, seq 0, length 64
09:49:13.599303 (authentic,confidential): SPI 0x08641654: IP 192.168.50.198 > 172.16.120.1: ICMP echo request, id 17957, seq 1, length 64
09:49:14.599476 (authentic,confidential): SPI 0x08641654: IP 192.168.50.198 > 172.16.120.1: ICMP echo request, id 17957, seq 2, length 64
09:49:15.598345 (authentic,confidential): SPI 0x08641654: IP 192.168.50.198 > 172.16.120.1: ICMP echo request, id 17957, seq 3, length 64

On Netasq I open a firewall rule that pass all on IPSec interface, but I have another 3 VPN on that netasq that work perfectly and I replicate the rules for this one…

![Schermata 2011-02-19 a 09.34.55.png](/public/imported_attachments/1/Schermata 2011-02-19 a 09.34.55.png)
![Schermata 2011-02-19 a 09.34.55.png_thumb](/public/imported_attachments/1/Schermata 2011-02-19 a 09.34.55.png_thumb)

psylo

First, can you ping anything else than Netasq interface. When doing that, can you dump on interface in of the Netasq?

sap68

@psylo:

First, can you ping anything else than Netasq interface. When doing that, can you dump on interface in of the Netasq?

I try to ping another Lan host (172.16.120.71) and dump IN interface of netasq (172.16.120.1):

tcpdump -ni eth0 host (Pfsense PublicIP) and icmp

But i see no packet.

psylo

If you dump on interface in, you'll normally see "deencapsulated" traffic and thus the source IP is the LAN IP (192.168.50.198).

sap68

@psylo:

If you dump on interface in, you'll normally see "deencapsulated" traffic and thus the source IP is the LAN IP (192.168.50.198).

You're right, but i have no luck :-/


U120XA0A0804150>tcpdump -ni eth0 host 192.168.50.198 and icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
0 packets captured
2637 packets received by filter
0 packets dropped by kernel

psylo

Ok. So, nothing appears on the LAN interface. So, it should be a firewalling problem… Do you have any rule which permits traffic from your LAN to the Netasq LAN?

Last, I suppose there is no route for the range 192.168.50.x on the Netasq. I mean: this range is not known by the Netasq except for your IPSEC tunnel.

sap68

@psylo:

Ok. So, nothing appears on the LAN interface. So, it should be a firewalling problem… Do you have any rule which permits traffic from your LAN to the Netasq LAN?

Last, I suppose there is no route for the range 192.168.50.x on the Netasq. I mean: this range is not known by the Netasq except for your IPSEC tunnel.

I have a rule that passAll on IPSec interface from any -> "networks internals" (LAN range)
Do you think it's necessary a static route for 192.168.50.x range?
Thank again for your help!

psylo

You don't need to add a route except if the IPsec is configured to "consider IPsec peer as internal". If IPsec is configured like that, you need to add a static route pointing to interface IPsec.

By the way, can you send a screenshot of the firewall rules on the Netasq?

I'll be unavailable for 1 hour.

sap68

@psylo:

You don't need to add a route except if the IPsec is configured to "consider IPsec peer as internal". If IPsec is configured like that, you need to add a static route pointing to interface IPsec.

By the way, can you send a screenshot of the firewall rules on the Netasq?

I'll be unavailable for 1 hour.

Ok, thanks!

This are the first 15 rules…

Rule number 12 it's this VPN.
Rule from 5 to 11 it's others (worked!) VPN...

![Schermata 2011-02-19 a 10.50.42.png_thumb](/public/imported_attachments/1/Schermata 2011-02-19 a 10.50.42.png_thumb)
![Schermata 2011-02-19 a 10.50.42.png](/public/imported_attachments/1/Schermata 2011-02-19 a 10.50.42.png)

psylo

Ok… The point is that you need to be authenticated on the Netasq before your traffic is allowed. This is the @ in the source column...

So, either you change that to get rid of the authentication. Either you authenticate yourself on the Netasq web interface...

Well, as we speak about IPSec tunnel, I strongly recommend to disable the authentication for those traffic (as traffics are already trusted).

sap68

@psylo:

Ok… The point is that you need to be authenticated on the Netasq before your traffic is allowed. This is the @ in the source column...

So, either you change that to get rid of the authentication. Either you authenticate yourself on the Netasq web interface...

Well, as we speak about IPSec tunnel, I strongly recommend to disable the authentication for those traffic (as traffics are already trusted).

Oh YES!
That work!

The problem is in the rule 12, I modify the rule so I permit traffic from 192.168.50.0 to Networks internal and now it worked!!!

MANY THANKS guys!

psylo

Great news but as said in my previous post, I strongly recommends 2 things for IPSec filtering:

disable authentication for IPSec tunnel as those traffic are already trusted. Except if you need authentication for HTTP proxy for example.
use network object (as you've done for your tunnel) for each tunnel…

sap68

@psylo:

Great news but as said in my previous post, I strongly recommends 2 things for IPSec filtering:

disable authentication for IPSec tunnel as those traffic are already trusted. Except if you need authentication for HTTP proxy for example.

use network object (as you've done for your tunnel) for each tunnel…

Disable auth.: I must disabled auth. also for IPsec mobile connection?

Thanks…

psylo

@sap68:

@psylo:

Great news but as said in my previous post, I strongly recommends 2 things for IPSec filtering:

disable authentication for IPSec tunnel as those traffic are already trusted. Except if you need authentication for HTTP proxy for example.

use network object (as you've done for your tunnel) for each tunnel…

Disable auth.: I must disabled auth. also for IPsec mobile connection?

Thanks…

Well… Actually, I don't know why you use Authentication for VPN tunnel (rules 5 to 11)... Normally, It's not necessary... But If you do that, you'll need to configure network objects defining all your remote networks in order to avoir security holes... Do you see what I mean?

sap68

@psylo:

@sap68:

@psylo:

Great news but as said in my previous post, I strongly recommends 2 things for IPSec filtering:

disable authentication for IPSec tunnel as those traffic are already trusted. Except if you need authentication for HTTP proxy for example.

use network object (as you've done for your tunnel) for each tunnel…

Disable auth.: I must disabled auth. also for IPsec mobile connection?

Thanks…

Well… Actually, I don't know why you use Authentication for VPN tunnel (rules 5 to 11)... Normally, It's not necessary... But If you do that, you'll need to configure network objects defining all your remote networks in order to avoir security holes... Do you see what I mean?

Yes, I understand.

I use this particular configuration (made with netasq support) for consent access from outside for some customer that needed access on particular server inside LAN.
Authentication VPN from <<any>> host it's (i think) only method to obtain the goal.
In particular I have a rule for every mobile access and i pass all traffic only to a host.

In you opinion it is a flaw in security?

Thanks…</any>

psylo

Ok… You're in an exception and this is not a security hole.
If you use only "any" as source, it could be a security hole but not with authentication.

BTW, good news your tunnel is working.