Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

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

    Scheduled Pinned Locked Moved General pfSense Questions
    41 Posts 3 Posters 7.7k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • stephenw10S
      stephenw10 Netgate Administrator
      last edited by

      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 1 Reply Last reply Reply Quote 0
      • S
        s_serra @stephenw10
        last edited by

        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

        1 Reply Last reply Reply Quote 0
        • stephenw10S
          stephenw10 Netgate Administrator
          last edited by

          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 2 Replies Last reply Reply Quote 0
          • S
            s_serra @stephenw10
            last edited by 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.

            1 Reply Last reply Reply Quote 0
            • S
              s_serra @stephenw10
              last edited by

              Good Morning,

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

              Compliments

              1 Reply Last reply Reply Quote 0
              • stephenw10S
                stephenw10 Netgate Administrator
                last edited by

                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 1 Reply Last reply Reply Quote 0
                • S
                  s_serra @stephenw10
                  last edited by

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

                  1 Reply Last reply Reply Quote 0
                  • stephenw10S
                    stephenw10 Netgate Administrator
                    last edited by

                    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 3 Replies Last reply Reply Quote 0
                    • S
                      s_serra @stephenw10
                      last edited by s_serra

                      This post is deleted!
                      1 Reply Last reply Reply Quote 0
                      • S
                        s_serra @stephenw10
                        last edited by 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

                        1 Reply Last reply Reply Quote 0
                        • S
                          s_serra @stephenw10
                          last edited by 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

                          1 Reply Last reply Reply Quote 0
                          • stephenw10S
                            stephenw10 Netgate Administrator
                            last edited by

                            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 1 Reply Last reply Reply Quote 0
                            • S
                              s_serra @stephenw10
                              last edited by

                              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?

                              1 Reply Last reply Reply Quote 0
                              • stephenw10S
                                stephenw10 Netgate Administrator
                                last edited by

                                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 1 Reply Last reply Reply Quote 0
                                • S
                                  s_serra @stephenw10
                                  last edited by

                                  @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
                                  
                                  1 Reply Last reply Reply Quote 0
                                  • stephenw10S
                                    stephenw10 Netgate Administrator
                                    last edited by

                                    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

                                    S 1 Reply Last reply Reply Quote 0
                                    • S
                                      s_serra @stephenw10
                                      last edited by

                                      @stephenw10

                                      Everything I try to ping to the outside gets no response.

                                      fb5d811d-bcd7-4f1e-829a-c655b32610da-image.png

                                      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.

                                      42bea0d3-0df8-4472-8bc2-5447820d95d9-image.png

                                      34008e30-49b2-4f42-91ee-9c6403f63f11-image.png

                                      1 Reply Last reply Reply Quote 0
                                      • stephenw10S
                                        stephenw10 Netgate Administrator
                                        last edited by

                                        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

                                        S 1 Reply Last reply Reply Quote 0
                                        • S
                                          s_serra @stephenw10
                                          last edited by s_serra

                                          @stephenw10
                                          8e0e880b-d6c6-4391-b18e-512db77859da-image.png

                                          185.113.141.145 is my remote pfsense wan ip

                                          db22db3b-519a-4e45-b20c-aa2399be01e6-image.png

                                          1 Reply Last reply Reply Quote 0
                                          • stephenw10S
                                            stephenw10 Netgate Administrator
                                            last edited by

                                            I meant traceroute the other way, from 185.113.143.50 out to something. Where it's failing.

                                            S 1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post
                                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.