Forward /29 through gre tunnel and allocate public ips on hosts.
-
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
-
I think so how can I see it?
-
Is the remote pfSense WAN IP address now in a different subnet? Outside 185.113.143.96/29?
-
Yes, the remote pfsense wan ip is out of the block.
-
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
-
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
-
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
-
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.
-
Good Morning,
I have already contacted my ISP and they have already done this to me. Forwarded /29 to pfsense's wan interface.
Compliments
-
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?
-
Yes I can already see when I ping, the packets arrive at the wan interface.
-
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
-
This post is deleted! -
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
-
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
-
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
-
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?
-
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
-
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 4011: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 -
Either something else is blocking it or 1.1.1.1 is just not responding.
Does that happen for any external IP you try to ping?
Clearly the route to 185.113.143.50 is still good since you are able to ping it.
Steve
