Forward /29 through gre tunnel and allocate public ips on hosts.
-
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
-
Everything I try to ping to the outside gets no response.
In the vlan I just have this rule in the local pfsense. On the remote pfsense I have the firewall turned off, it's just for routing.
-
Try running a traceroute. It looks like something is blocking outbound traffic but it's not either of the pfSense boxes. The pcap shows the traffic leaving the remote WAN interface exactly as expected.
Steve
-
-
I meant traceroute the other way, from 185.113.143.50 out to something. Where it's failing.
-
root@teste:~# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0@if25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether f2:b5:b6:9a:c0:aa brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 185.113.143.50/28 brd 185.113.143.63 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::f0b5:b6ff:fe9a:c0aa/64 scope link valid_lft forever preferred_lft forever root@teste:~# traceroute google.com traceroute to google.com (142.250.184.174), 30 hops max, 60 byte packets 1 10.0.2.2 (10.0.2.2) 8.151 ms 8.112 ms 8.087 ms 2 gw-141.i4w.pt (185.113.141.1) 8.250 ms 8.252 ms 8.265 ms 3 172.16.8.2 (172.16.8.2) 8.402 ms 8.373 ms 8.355 ms 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * root@teste:~#root@teste:~# traceroute 185.83.212.22 traceroute to 185.83.212.22 (185.83.212.22), 30 hops max, 60 byte packets 1 10.0.2.2 (10.0.2.2) 8.377 ms 8.336 ms 8.310 ms 2 gw-141.i4w.pt (185.113.141.1) 8.664 ms 8.635 ms 8.611 ms 3 NOS.AS2860.gigapix.pt (193.136.251.4) 9.810 ms 9.785 ms 9.949 ms 4 * * * 5 * * * 6 pt1.cr1.as44222.net (185.83.212.11) 13.488 ms 13.176 ms 13.130 ms 7 * * * 8 * * * 9 * * * ....... -
Hmm, that 2nd trace looks like it's succeeding, just the target not responding.
Can it ping 185.83.212.22? That responds for me.
Steve
-
Traceroute is working strangely. Ping does not work.
Curl to ifconfig.me to check external ip doesn't work either.
root@teste:~# traceroute 185.83.212.22 traceroute to 185.83.212.22 (185.83.212.22), 30 hops max, 60 byte packets 1 10.0.2.2 (10.0.2.2) 8.143 ms 8.094 ms 8.068 ms 2 gw-141.i4w.pt (185.113.141.1) 8.473 ms 8.448 ms 8.424 ms 3 NOS.AS2860.gigapix.pt (193.136.251.4) 9.113 ms 9.088 ms 9.173 ms 4 * * * 5 * * * 6 pt1.cr1.as44222.net (185.83.212.11) 13.342 ms 13.255 ms 13.206 ms 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * root@teste:~# ping 185.83.212.22 PING 185.83.212.22 (185.83.212.22) 56(84) bytes of data. ^C --- 185.83.212.22 ping statistics --- 9 packets transmitted, 0 received, 100% packet loss, time 8171ms -
What about if you traceroute with ICMP?:
traceroute -I 185.83.212.22That completes for me here.
