Forward /29 through gre tunnel and allocate public ips on hosts.

s_serra

Hello, I have some doubts how to forward a /29 block through a gre tunnel and allocate the ips on the hosts on the local pfsense side. In local pfsense do I have to create a /29 network? And in remote pfsense how do I get them out to the internet? The gre tunnel is already created and communicating.

My isp provided the following information:

Network: 185.113.143.96/29
Broadcast: 185,113,143,103
HostMin: 185.113.143.97
HostMax: 185,113,143,102

Compliments

stephenw10

Did you get a new subnet routed to you then?

If it's still supplied directly at the WAN of the remote pfSense you cannot use it directly on hosts at the local end of the tunnel.

Steve

s_serra

I think so how can I see it?

stephenw10

Is the remote pfSense WAN IP address now in a different subnet? Outside 185.113.143.96/29?

s_serra

Yes, the remote pfsense wan ip is out of the block.

stephenw10

Ok, then I would test to see if it's being routed to the WAN IP.

Disable/remove any VIPs you have there for the /29.

Send some pings to an IP in the /29 from some external public IP.

Those pings should appear on the remote pfSense WAN in a packet capture if the ISP is routing traffic for that sub net to you.

If that is the case then you can use that subnet however you want internally on your network. You would just need to add the static routes to send it over the tunnel.

Steve

s_serra

I ping the address 185.113.143.103 but didn't get any response on the wan interface. I'll try to talk to the ISP to see if they can route their routers from the /29 block to my pfsense wan remote ip (185.113.141.145). Thanks

stephenw10

You wouldn't expect to get a response to the ping unless you have set something up to respond to it. You just need to run a pcap for that IP and make sure the ping requests are arriving without a VIP configured for it.

The alternative to routing it to you is they simply provide the subnet on the WAN directly and expect to be able to ARP for it before sending and traffic. In that case you need to add VIPs for the IPs on the pfSense WAN and cannot use the IPs on hosts dircetly.

Steve

s_serra

I run packet capture on the remote pfsense wan interface and put the external ip and nothing arrived on the wan interface. Wasn't it supposed to do that? I don't know how to use pcap so I used packet capture from pfsense.

s_serra

Good Morning,

I have already contacted my ISP and they have already done this to me. Forwarded /29 to pfsense's wan interface.

Compliments

stephenw10

If the ISP is routing the /29 to your WAN IP then you should see packets arrive there in a pcap.

What pcap settings did you use? How were you sending the traffic?

s_serra

Yes I can already see when I ping, the packets arrive at the wan interface.

stephenw10

Great, in that case you can route that however you want. Or use it on the remote firewall as VIPs if you need to.

So in your case you probably want to add a static route on the remote pfSense to route the /29 to the local end of the GRE tunnel via the GRE gateway. Then you can use the /29 subnet directly on an interface in the local pfSense. Hosts in that subnet can use the public IPs directly. You will still need the policy routing to send traffic from them over the tunnel of course.

Steve

s_serra

This post is deleted!

s_serra

One more question, instead of my ISP forwarding the /29 o to the wan of my remote pfsense, couldn't I do it to the wan of my local pfsense? That way I didn't need the remote pfsense.

Thanks

s_serra

I already managed to configure it.

I created a static route on the remote pfsense forward the /29 through the gre tunnel. And in the local pfsense I disabled the NAT for the /29 in the tunnel gre and in the firewall in the VLAN I put the gateway of the tunnel gre. On the VLAN interface I put the ip 185.113.143.97. On the host I put the ip 185.113.143.100/32 to test with the gateway 185.113.143.97.

I would like to know if this is the best way to do this.

Thanks

stephenw10

Yes, that sounds correct. Is it working as expected?

But, yes, if your ISP can route the /29 to the local pfSense WAN directly then you can remove the remote pfSense and the GRE tunnel entirely which would be much better. My understanding was that you could not get and static IPs at the local pfSense. Or the traffic was filtered.

Steve

s_serra

Yes it worked as expected. My isp said that for technical and political reasons it could not forward /29 to an external address. Instead of using gre tunnel can I forward /29 from remote pfsense to my local pfsense ip instead of using gre tunnel?

stephenw10

No, you need to have some sort of tunnel to route across. You can't just route traffic to an IP in a different subnet.
You might be able to run some sort of proxy and redirect traffic on different ports. That would be outside pfSense though.

Steve

s_serra

@stephenw10

Something strange has happened in the last few days. If I ping the ip 185.113.143.50, it goes through the remote pfsense and the local pfsense until it reaches the virtual machine and I get a response. When I ping from inside the virtual machine to the outside, it passes through local and remote pfsense but does not receive the ping response.

Below I send two pcaps the first is me pinging my pc and I get a response the second is me pinging the virtual machine and I don't get a response on the virtual machine. These two pcaps were made in the remote pfsense on the wan interface.

Thanks

11:46:37.039207 00:16:3c:d5:dc:45 > 00:00:5e:00:01:0b, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 62, id 64165, offset 0, flags [none], proto ICMP (1), length 60)
    185.113.143.50 > 193.137.65.16: ICMP echo reply, id 1, seq 147, length 40
11:46:37.362149 00:00:5e:00:01:0d > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 185.113.143.50 tell 185.113.143.1, length 46
11:46:38.040709 00:00:5e:00:01:0b > 00:16:3c:d5:dc:45, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 120, id 15176, offset 0, flags [none], proto ICMP (1), length 60)
    193.137.65.16 > 185.113.143.50: ICMP echo request, id 1, seq 148, length 40
11:46:38.049015 00:16:3c:d5:dc:45 > 00:00:5e:00:01:0b, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 62, id 64240, offset 0, flags [none], proto ICMP (1), length 60)
    185.113.143.50 > 193.137.65.16: ICMP echo reply, id 1, seq 148, length 40

11:42:13.334730 00:16:3c:d5:dc:45 > 00:00:5e:00:01:0b, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 63699, offset 0, flags [DF], proto ICMP (1), length 84)
    185.113.143.50 > 1.1.1.1: ICMP echo request, id 59694, seq 28, length 64
11:42:14.358678 00:16:3c:d5:dc:45 > 00:00:5e:00:01:0b, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 63794, offset 0, flags [DF], proto ICMP (1), length 84)
    185.113.143.50 > 1.1.1.1: ICMP echo request, id 59694, seq 29, length 64
11:42:15.382590 00:16:3c:d5:dc:45 > 00:00:5e:00:01:0b, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 63795, offset 0, flags [DF], proto ICMP (1), length 84)
    185.113.143.50 > 1.1.1.1: ICMP echo request, id 59694, seq 30, length 64
11:42:16.406529 00:16:3c:d5:dc:45 > 00:00:5e:00:01:0b, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 64029, offset 0, flags [DF], proto ICMP (1), length 84)
    185.113.143.50 > 1.1.1.1: ICMP echo request, id 59694, seq 31, length 64