CaptivePortal on GRE interface

rvolwater

We're currently trying to set up the following:
Mobile devices on 10.30.0.0/16 -> GRE tunnel over IPSEC VPN -> pfSense server -> Internet

On a separate network connected to pfSense is a DNS/DHCP server (I needed a separate DHCP server to be able to serve the 10.30.0.0/16 subnet, which isn't directly connected on pfSense)

Traffic flows from devices to Internet; however, I have CaptivePortal set up on all interfaces, but no traffic is blocked/accounted. CaptivePortal doesn't seem to work on the GRE interface.

Questions:

Is it possible to enable the CaptivePortal on the GRE interface?
If that's not possible, it is possible to forward the traffic to another interface on the same pfSense server, and enable CaptivePortal there?

Gertjan

Hello,

You have a design (image) to make all this clear ?

"Captive Portal on pfSEnse", AND "use the DHCP server on pfsense" (if not: troubles …)

rvolwater

I've tried to fit it in a picture. I'm not sure how to show the GRE over IPSEC tunnel:

Do we need to run the DHCP server (and maybe DNS too) on the pfSense server to get the Captive Portal to work? I can't enable DHCP server on the GRE interface. I've tried setting the DHCP server up on a new interface, but can't assign the range 10.30.0.0/16 (as this doesn't fit in the range on that new interface). Also, I'm not sure if it would be possible to send traffic to that new interface.

The current DHCP server on 10.65.3.40 uses Debian ISC DHCP with "shared-network" to allow serving IP adresses for the 'unknown' network.

We're running pfSense 2.2.5.

rvolwater

I've modified the setup so we now use 2 VM's; 1 for the setup of VPN, and 1 with a LAN interface to run CaptivePortal on:

Will this setup still work? It seems the MAC addresses from the client devices (10.30.0.0/16) are dropped for the traffic that flows through the VPN tunnel. The DHCP requests however are still done with correct source MAC.

A followup question; the traffic flows through both VM's, ping works correctly:

[2.2.6-RELEASE][admin@HopprVPN.trin-it.nl]/root: tcpdump -netti le1 host tweakers.net
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on le1, link-type EN10MB (Ethernet), capture size 65535 bytes
capability mode sandbox enabled
1451471556.841142 00:50:56:01:26:5e > 00:50:56:01:27:ca, ethertype IPv4 (0x0800), length 74: 10.30.0.10 > 213.239.154.20: ICMP echo request, id 1, seq 1127, length 40
1451471556.842799 00:50:56:01:27:ca > 00:50:56:01:26:5e, ethertype IPv4 (0x0800), length 74: 213.239.154.20 > 10.30.0.10: ICMP echo reply, id 1, seq 1127, length 40
1451471557.850062 00:50:56:01:26:5e > 00:50:56:01:27:ca, ethertype IPv4 (0x0800), length 74: 10.30.0.10 > 213.239.154.20: ICMP echo request, id 1, seq 1128, length 40
1451471557.851729 00:50:56:01:27:ca > 00:50:56:01:26:5e, ethertype IPv4 (0x0800), length 74: 213.239.154.20 > 10.30.0.10: ICMP echo reply, id 1, seq 1128, length 40
1451471559.059122 00:50:56:01:26:5e > 00:50:56:01:27:ca, ethertype IPv4 (0x0800), length 74: 10.30.0.10 > 213.239.154.20: ICMP echo request, id 1, seq 1129, length 40
1451471559.060913 00:50:56:01:27:ca > 00:50:56:01:26:5e, ethertype IPv4 (0x0800), length 74: 213.239.154.20 > 10.30.0.10: ICMP echo reply, id 1, seq 1129, length 40
1451471559.999093 00:50:56:01:26:5e > 00:50:56:01:27:ca, ethertype IPv4 (0x0800), length 74: 10.30.0.10 > 213.239.154.20: ICMP echo request, id 1, seq 1130, length 40
1451471560.000694 00:50:56:01:27:ca > 00:50:56:01:26:5e, ethertype IPv4 (0x0800), length 74: 213.239.154.20 > 10.30.0.10: ICMP echo reply, id 1, seq 1130, length 40

But on return for TCP traffic the LAN interface on the first VM returns 'host unreachable' for the client device (and TCP traffic is never returned to the client device):

1451471585.431692 00:50:56:01:26:5e > 00:50:56:01:27:ca, ethertype IPv4 (0x0800), length 66: 10.30.0.10.61580 > 213.239.154.20.80: Flags [s], seq 4232436194, win 8192, options [mss 1160,nop,wscale 8,nop,nop,sackOK], length 0
1451471585.433843 00:50:56:01:27:ca > 00:50:56:01:26:5e, ethertype IPv4 (0x0800), length 66: 213.239.154.20.80 > 10.30.0.10.61580: Flags [S.], seq 2346278513, ack 4232436195, win 28960, options [mss 1160,nop,wscale 0,nop,nop,sackOK], length 0
1451471585.433878 00:50:56:01:26:5e > 00:50:56:01:27:ca, ethertype IPv4 (0x0800), length 94: 10.20.0.48 > 213.239.154.20: ICMP host 10.30.0.10 unreachable, length 60
1451471588.467043 00:50:56:01:26:5e > 00:50:56:01:27:ca, ethertype IPv4 (0x0800), length 66: 10.30.0.10.61580 > 213.239.154.20.80: Flags [s], seq 4232436194, win 8192, options [mss 1160,nop,wscale 8,nop,nop,sackOK], length 0
1451471588.468891 00:50:56:01:27:ca > 00:50:56:01:26:5e, ethertype IPv4 (0x0800), length 66: 213.239.154.20.80 > 10.30.0.10.61580: Flags [S.], seq 2346278513, ack 4232436195, win 28960, options [mss 1160,nop,wscale 0,nop,nop,sackOK], length 0
1451471588.468918 00:50:56:01:26:5e > 00:50:56:01:27:ca, ethertype IPv4 (0x0800), length 94: 10.20.0.48 > 213.239.154.20: ICMP host 10.30.0.10 unreachable, length 60

I think this is because the LAN interface has no knowledge of the traffic that's being returned, so it blocks the Syn/Ack packets. See also firewall logs:
[img]http://www2.trin-it.nl/download/tweakers_syn_ack.png[/img]

How can I solve this?

Thanks for any help.[/s][/s]