WAN DHCP Asign public ip



  • My speedtouch can assign public ip to pfsense, however when I do this I lose internet connectivity. My speedtouch assigning a normal private ip address and working in normal router mode and internet works fine. Why could this be?



  • There are many possible causes. It would be helpful to have more details to reduce the number of causes that need to be considered.

    What do you mean by "lose internet connectivity"?

    • Can't ping internet host web pages by hostname from pfSense console (might be DNS problem)?

    • Can't ping internet host by IP address from pfSense console (might be routing problem)?

    • Can't access web page by name or IP address from computer connected to pfSense LAN interface (might be client configuration problem)?

    • Can't access web page by name or IP address from computer connected to pfSense OPTx interface (might be firewall rule problem)?

    What model speedtouch?

    You switched the modem from routing to bridge mode?

    Is your WAN connection ADSL or cable or something else?

    Your WAN link to ISP uses DHCP? PPP?



  • I am testing pfsense on vmware workstation
    The speedtouch is a 780wl, and I am on PPPoA ADSL.  When the router supplied a private ip address to the pfsense wan it works fine. When I take the option on the speedtouch to "assign public ip to device" and select pfsense the wan of pfsense duly picks up my public address.

    I did not change router to bridge mode and isp supplies an address via dhcp.

    I cant ping by ip address or domain name from either pfsense or a lan computer when the wan of pfsense has the public ip address.

    I did get this to work on a smoothwall so dont think it is the speedtouch.



  • I presume your pfSense WAN interface is configured by DHCP. What parameters does DHCP supply? default gateway? IP Address? Netmask? IP address of DNS?

    When you switch the modem mode to "assign public IP to device" do you restart BOTH the modem and pfSense?



  • Yes DHCP.  I'll double check the rest later but from memory it was getting the public ip andd a isp gateway. I set DNS manually but maybe I have not done this correctly, cant get to the machine now.

    Yes I did reboot both devices..



  • When you get access to the machine please collect and post the dhclient output from the system log and the output of pfSense shell command netstat -r -n (the route table).

    Do you get a response when you attempt to ping the ISP gateway by IP address?


  • LAYER 8 Global Moderator

    @bilbo:

    I am testing pfsense on vmware workstation
    I cant ping by ip address or domain name from either pfsense or a lan computer when the wan of pfsense has the public ip address.
    I did get this to work on a smoothwall so dont think it is the speedtouch.

    And how are you testing exactly once your VM gets the public IP, and how exactly is this VM connected to your modem/router

    Do you have bridged interfaces or nat in your vm setup, where does the cable from your modem/router run to this workstation?

    I would suggest you layout your VM setup for us, and how your wired for this testing and then we can help you figure out what your doing wrong.



  • See below for various logs

    The host has actual two nics which are in bridge mode in vmware. The wan is connected to the speedtouch with all protocols disabled except vmware. The lan is connected to an netgear configured as access point.

    Nothing seems pingable from pfsense when the public ip is assigned to the pfsense wan including the gateway. I can ping the public wan ip. No internet access at all from the lan side.

    kernel: arpresolve: can't allocate llinfo for

    Jan 23 20:35:31 dhcpd: DHCPDISCOVER from 00:1d:92:dd:1a:0d (OSCAR) via em1
    Jan 23 20:35:31 dhcpd: DHCPOFFER on 192.168.0.100 to 00:1d:92:dd:1a:0d (OSCAR) via em1
    Jan 23 20:35:31 dhcpd: DHCPREQUEST for 192.168.0.100 (192.168.0.11) from 00:1d:92:dd:1a:0d (OSCAR) via em1
    Jan 23 20:35:31 dhcpd: DHCPACK on 192.168.0.100 to 00:1d:92:dd:1a:0d (OSCAR) via em1
    Jan 23 20:35:34 dhcpd: DHCPINFORM from 192.168.0.100 via em1
    Jan 23 20:35:34 dhcpd: DHCPACK to 192.168.0.100 (00:1d:92:dd:1a:0d) via em1
    Jan 23 20:39:09 dhcpd: DHCPINFORM from 192.168.0.100 via em1
    Jan 23 20:39:09 dhcpd: DHCPACK to 192.168.0.100 (00:1d:92:dd:1a:0d) via em1
    Jan 23 20:40:09 dhcpd: Internet Systems Consortium DHCP Server 4.2.3
    Jan 23 20:40:09 dhcpd: Copyright 2004-2011 Internet Systems Consortium.
    Jan 23 20:40:09 dhcpd: All rights reserved.
    Jan 23 20:40:09 dhcpd: For info, please visit https://www.isc.org/software/dhcp/
    Jan 23 20:40:09 dhcpd: Wrote 5 leases to leases file.
    Jan 23 20:40:09 dhcpd: Listening on BPF/em1/00:0c:29:c7:7a:7b/192.168.0.0/24
    Jan 23 20:40:09 dhcpd: Sending on BPF/em1/00:0c:29:c7:7a:7b/192.168.0.0/24
    Jan 23 20:40:09 dhcpd: Sending on Socket/fallback/fallback-net
    Jan 23 20:42:17 dhcpd: DHCPINFORM from 192.168.0.100 via em1
    Jan 23 20:42:17 dhcpd: DHCPACK to 192.168.0.100 (00:1d:92:dd:1a:0d) via em1
    Jan 23 20:52:56 dhcpd: DHCPINFORM from 192.168.0.100 via em1
    Jan 23 20:52:56 dhcpd: DHCPACK to 192.168.0.100 (00:1d:92:dd:1a:0d) via em1
    Jan 23 20:53:03 dhcpd: Internet Systems Consortium DHCP Server 4.2.3
    Jan 23 20:53:03 dhcpd: Copyright 2004-2011 Internet Systems Consortium.
    Jan 23 20:53:03 dhcpd: All rights reserved.
    Jan 23 20:53:03 dhcpd: For info, please visit https://www.isc.org/software/dhcp/
    Jan 23 20:53:03 dhcpd: Wrote 5 leases to leases file.
    Jan 23 20:53:03 dhcpd: Listening on BPF/em1/00:0c:29:c7:7a:7b/192.168.0.0/24
    Jan 23 20:53:03 dhcpd: Sending on BPF/em1/00:0c:29:c7:7a:7b/192.168.0.0/24
    Jan 23 20:53:03 dhcpd: Sending on Socket/fallback/fallback-net
    Jan 23 20:53:07 dhcpd: Internet Systems Consortium DHCP Server 4.2.3
    Jan 23 20:53:07 dhcpd: Copyright 2004-2011 Internet Systems Consortium.
    Jan 23 20:53:07 dhcpd: All rights reserved.
    Jan 23 20:53:07 dhcpd: For info, please visit https://www.isc.org/software/dhcp/
    Jan 23 20:53:07 dhcpd: Wrote 5 leases to leases file.
    Jan 23 20:53:07 dhcpd: Listening on BPF/em1/00:0c:29:c7:7a:7b/192.168.0.0/24
    Jan 23 20:53:07 dhcpd: Sending on BPF/em1/00:0c:29:c7:7a:7b/192.168.0.0/24
    Jan 23 20:53:07 dhcpd: Sending on Socket/fallback/fallback-net
    Jan 23 20:53:09 dhcpd: Internet Systems Consortium DHCP Server 4.2.3
    Jan 23 20:53:09 dhcpd: Copyright 2004-2011 Internet Systems Consortium.
    Jan 23 20:53:09 dhcpd: All rights reserved.
    Jan 23 20:53:09 dhcpd: For info, please visit https://www.isc.org/software/dhcp/
    Jan 23 20:53:09 dhcpd: Wrote 5 leases to leases file.
    Jan 23 20:53:09 dhcpd: Listening on BPF/em1/00:0c:29:c7:7a:7b/192.168.0.0/24
    Jan 23 20:53:09 dhcpd: Sending on BPF/em1/00:0c:29:c7:7a:7b/192.168.0.0/24
    Jan 23 20:53:09 dhcpd: Sending on Socket/fallback/fallback-net
    Jan 23 20:54:28 dhcpd: DHCPREQUEST for 192.168.0.4 from 18:e7:f4:6e:a0:dc via em1: unknown lease 192.168.0.4.
    Jan 23 20:54:31 dhcpd: DHCPREQUEST for 192.168.0.4 from 18:e7:f4:6e:a0:dc via em1: unknown lease 192.168.0.4.
    Jan 23 20:54:35 dhcpd: DHCPDISCOVER from 18:e7:f4:6e:a0:dc (Emilys-iPod) via em1
    Jan 23 20:54:36 dhcpd: DHCPOFFER on 192.168.0.103 to 18:e7:f4:6e:a0:dc (Emilys-iPod) via em1
    Jan 23 20:54:37 dhcpd: DHCPREQUEST for 192.168.0.103 (192.168.0.11) from 18:e7:f4:6e:a0:dc (Emilys-iPod) via em1
    Jan 23 20:54:37 dhcpd: DHCPACK on 192.168.0.103 to 18:e7:f4:6e:a0:dc (Emilys-iPod) via em1

    $ netstat -r -n
    Routing tables

    Internet:
    Destination        Gateway            Flags    Refs      Use  Netif Expire
    46.0.0.0/8        link#1            U          0        0    em0
    46.31.x.x      link#1            UHS        0        0    lo0
    127.0.0.1          link#7            UH          0      41    lo0
    192.168.0.0/24    link#2            U          0    1521    em1
    192.168.0.11      link#2            UHS        0        0    lo0

    Internet6:
    Destination                      Gateway                      Flags      Netif Expire
    ::1                              ::1                          UH          lo0
    fe80::%em0/64                    link#1                        U          em0
    fe80::20c:29ff:fec7:7a71%em0      link#1                        UHS        lo0
    fe80::%em1/64                    link#2                        U          em1
    fe80::20c:29ff:fec7:7a7b%em1      link#2                        UHS        lo0
    fe80::%lo0/64                    link#7                        U          lo0
    fe80::1%lo0                      link#7                        UHS        lo0
    ff01:1::/32                      fe80::20c:29ff:fec7:7a71%em0  U          em0
    ff01:2::/32                      fe80::20c:29ff:fec7:7a7b%em1  U          em1
    ff01:7::/32                      ::1                          U          lo0
    ff02::%em0/32                    fe80::20c:29ff:fec7:7a71%em0  U          em0
    ff02::%em1/32                    fe80::20c:29ff:fec7:7a7b%em1  U          em1
    ff02::%lo0/32                    ::1                          U          lo0

    gateways
    Name Gateway Monitor RTT Loss Status Description
    WAN 195.10.125.82 195.10.125.82 0.000ms 100.0%
    Offline
    Interface WAN Dynamic Gateway



  • The reason you can't get to the internet is that there is no default route. (The first route in the netstat -r -n output should begin default in the Destination column.)

    The DHCP server that provides details for your WAN interface should also provide the default gateway. It could be useful to have the dhclient records from the pfSense system log. (You provided the dhcpd (DHCP SERVER) records.)

    Apparently netstat reported a gateway of 192.10.125.82. What system has this IP address?  Your ISP gateway? Your modem? Any idea why this entry appears? Its seems to be marked offline. Regardless, there is no route to it so there is no way it can act as a gateway for you in the current configuration.



  • woops heres dhclient

    Jan 24 20:52:30 dhclient[6965]: connection closed
    Jan 24 20:52:30 dhclient[6965]: connection closed
    Jan 24 20:52:30 dhclient[6965]: exiting.
    Jan 24 20:52:30 dhclient[6965]: exiting.
    Jan 24 20:52:42 dhclient: PREINIT
    Jan 24 20:52:42 dhclient[23280]: DHCPREQUEST on em0 to 255.255.255.255 port 67
    Jan 24 20:52:42 dhclient[23280]: DHCPACK from 192.168.1.254
    Jan 24 20:52:42 dhclient: REBOOT
    Jan 24 20:52:42 dhclient: Starting add_new_address()
    Jan 24 20:52:42 dhclient: ifconfig em0 inet 46.31.x.x netmask 255.0.0.0 broadcast 46.255.255.255
    Jan 24 20:52:42 dhclient: New IP Address (em0): 46.31.x.x
    Jan 24 20:52:42 dhclient: New Subnet Mask (em0): 255.0.0.0
    Jan 24 20:52:42 dhclient: New Broadcast Address (em0): 46.255.255.255
    Jan 24 20:52:42 dhclient: New Routers (em0): 195.10.125.82
    Jan 24 20:52:42 dhclient: Adding new routes to interface: em0
    Jan 24 20:52:42 dhclient: /sbin/route add default 195.10.125.82
    Jan 24 20:52:42 dhclient: Creating resolv.conf
    Jan 24 20:52:42 dhclient[23280]: bound to 46.31.x.x – renewal in 2147483647 seconds.

    According to my router:

    IP Address 46.31.x.x

    IP Subnet Mask 255.255.255.255
    Gateway IP Address 195.10.125.82  <= isp gateway
    Domain Name Server
    208.67.222.222
    208.67.220.220

    According to the routing table on the router:

    Destination Mask Gateway Metric Active
    195.10.125.82 255.255.255.255 0.0.0.0 0 Yes
    192.168.0.0 255.255.255.0 0.0.0.0 0 Yes
    0.0.0.0 0.0.0.0 195.10.125.82 0 Yes

    So presumably I need to add a static route as above excluding the middle?



  • Your configuration is rather difficult for FreeBSD to work with.

    Your WAN IP address is 46.31.x.x/8. Your default gateway is 195.10.125.82. Your default gateway is not on the WAN net and there is no gateway on the WAN net to get to the default gateway.

    Your DHCP server has IP address 192.168.1.254 a private IP address. Whose server is that? Why is it telling this particular client to use an "off network" default gateway? It should specify a default gateway on the network of the interface.



  • The 192.168.1.254 is the speedtouch. Once this assigns the public ip to pfsense I would presume it becomes invisible to pfsense and should just forward traffic like a dumb modem?



  • @bilbo:

    The 192.168.1.254 is the speedtouch. Once this assigns the public ip to pfsense I would presume it becomes invisible to pfsense and should just forward traffic like a dumb modem?

    If that's what is supposed to happen then the speedtouch should give its IP address as the IP address of the default gateway.

    I have a dumb ADSL modem on my home network and it does "ppp passthrough" with the ADSL link, consequently my pfSense WAN link is a PPPoE link.

    I downloaded what claims to be the manual for the Speedtouch 780wl and I suspect it would be more effective to configure pfSense WAN interface for PPPoE and the speedtouch in Bridged Ethernet or Routed PPPoE (with PPPoE relay) (p40 of the manual I downloaded). Unfortunately a quick search didn't turn up any more details about these modes nor what assign public IP does.



  • Unfortunately am on a PPPoA connection, hence this problem.

    I did assign public ip address to a laptop here and had internet connectivity.

    Ethernet adapter Local Area Connection:

    Connection-specific DNS Suffix  . : lan
      Link-local IPv6 Address . . . . . : fe80::d10c:14c9:
      IPv4 Address. . . . . . . . . . . : 46.131.123.123
      Subnet Mask . . . . . . . . . . . : 255.0.0.0
      Default Gateway . . . . . . . . . : 195.10.125.82

    Tunnel adapter isatap.{5527EAED-CAD0-4A40-AE31-608A0A93A241}:

    Media State . . . . . . . . . . . : Media disconnected
      Connection-specific DNS Suffix  . :

    Tunnel adapter Teredo Tunneling Pseudo-Interface:

    Media State . . . . . . . . . . . : Media disconnected
      Connection-specific DNS Suffix  . :

    Tunnel adapter 6TO4 Adapter:

    Connection-specific DNS Suffix  . : lan
      IPv6 Address. . . . . . . . . . . : 2002:2e1f:ceb6::2e1f:ceb6
      Default Gateway . . . . . . . . . :

    C:\Users\Bil>PING 195.10.125.82

    Pinging 195.10.125.82 with 32 bytes of data:
    Request timed out.

    Ping statistics for 195.10.125.82:
        Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),
    Control-C
    ^C
    C:\Users\Bil>ROUTE PRINT

    Interface List
    16…00 1c 23 09 df fa ......Broadcom NetXtreme 57xx Gigabit Controller
      1...........................Software Loopback Interface 1
    21...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
    12...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
    13...00 00 00 00 00 00 00 e0 Microsoft 6to4 Adapter

    IPv4 Route Table

    Active Routes:
    Network Destination        Netmask          Gateway      Interface  Metric
              0.0.0.0          0.0.0.0    195.10.125.82    46.123.123.123    20
            46.0.0.0        255.0.0.0        On-link    46.123.123.123    276
        46.123.123.123  255.255.255.255        On-link    46.123.123.123  276
      46.255.255.255  255.255.255.255        On-link    46.123.123.123    276
            127.0.0.0        255.0.0.0        On-link        127.0.0.1    306
            127.0.0.1  255.255.255.255        On-link        127.0.0.1    306
      127.255.255.255  255.255.255.255        On-link        127.0.0.1    306
            224.0.0.0        240.0.0.0        On-link        127.0.0.1    306
            224.0.0.0        240.0.0.0        On-link    46.123.123.123    276
      255.255.255.255  255.255.255.255        On-link        127.0.0.1    306
      255.255.255.255  255.255.255.255        On-link    46.123.123.123  276

    C:\Users\Bil>PING 8.8.8.8

    Pinging 8.8.8.8 with 32 bytes of data:
    Reply from 8.8.8.8: bytes=32 time=55ms TTL=51
    Reply from 8.8.8.8: bytes=32 time=56ms TTL=51
    Reply from 8.8.8.8: bytes=32 time=55ms TTL=51
    Reply from 8.8.8.8: bytes=32 time=56ms TTL=51

    Ping statistics for 8.8.8.8:
        Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
        Minimum = 55ms, Maximum = 56ms, Average = 55ms

    C:\Users\Bil>TRACERT 8.8.8.8

    Tracing route to google-public-dns-a.google.com [8.8.8.8]
    over a maximum of 30 hops:

    1    6 ms    99 ms    99 ms  dsldevice.lan [192.168.1.254]            <==== how does it doe this?
      2    *      74 ms    32 ms  195.10.125.113
      3    32 ms    33 ms    32 ms  195.10.125.114
      4    32 ms    31 ms    33 ms  195.10.119.142
      5    56 ms    45 ms    46 ms  195.50.122.145
      6    46 ms    46 ms    46 ms  195.50.122.82
      7    46 ms    49 ms    51 ms  209.85.255.76
      8    46 ms    46 ms    46 ms  209.85.253.196
      9    53 ms    52 ms    53 ms  209.85.243.33
    10  106 ms  159 ms  105 ms  216.239.49.36
    11    56 ms    *        *    209.85.255.118
    etc…...



  • @bilbo:

    Unfortunately am on a PPPoA connection, hence this problem.

    PPPoA = PPP over ATM. PPPoE = PPP over Ethernet. I haven't looked into it but I suspect the differences are purely related to the different communications media: ATM headers and segmentation vs Ethernet headers.

    The document I downloaded specifically discusses PPPoE on the router LAN side and PPPoA or PPPoE on the WAN side without any mention of restriction on translation between the two.

    @bilbo:

    I did assign public ip address to a laptop here and had internet connectivity.

    Windows laptop? Windows is not FreeBSD!

    @bilbo:

    C:\Users\Bil>TRACERT 8.8.8.8

    Tracing route to google-public-dns-a.google.com [8.8.8.8]
    over a maximum of 30 hops:

    1    6 ms    99 ms    99 ms  dsldevice.lan [192.168.1.254]            <==== how does it doe this?

    I don't know. Maybe the modem looks for traceroute packets and responds.

    Its clear DHCP from your modem says IP address: 46.x.x.x and default gateway 195.10.125.82. This information alone is insufficient in that it doesn't provide a way to get to 195.10.125.82. Perhaps the route is, by convention, implied: "use the interface on which DHCP information was received". Perhaps the information is provided in some DHCP options. Further investigation is required to answer the question "How does Windows know which interface to use to get to 195.10.125.82?" ARP on ALL LAN interfaces?

    dhclient reported: Jan 24 20:52:42    dhclient: /sbin/route add default 195.10.125.82 PERHAPS this is the command dhclient uses to tell the kernel the default gateway.  There is no information here to tell the kernel how to get to 195.10.125.82 because 195.10.125.80 is not in any network to which the computer is connected. The FreeBSD man page suggests the route command can have arguments specifying what interface to use. My very limited testing suggests that facility is broken or the documentation about this facility is woefully inadequate.

    I suggest your options include:
    1. If you insist on using the modem's "assign public IP" mode and pfSense you are venturing along a less commonly travelled path and should be prepared for a considerable time investment.
    2. If you insist on using the modem's "assign public IP mode" and don't care which firewall/router you use there are probably a number of options. Maybe you could even use m0n0wall which is very like pfSense but it MIGHT have a differnet combination of packages that work with the modem's "assign public IP" mode.
    3. You could try the modem configured for PPPoA on WAN, PPPoE on LAN and pfSense's wan interface in PPPoE.
    4. You could try a "dumb" ADSL modem (such as the Tenda D820B which I have been using for over a year and cost me less that the local equivalent of US$20) with pfSense's WAN interface in PPPoE.

    Here are some examples of the things I saw when trying to manipulate a route specifying an interface (I was attempting to create and reference a route to 10.0.0.0/8 with gateway 195.10.182.82 accessed through interface vr0)

    The man page is not clear about the command syntax:```

    [2.0.1-RELEASE][root@pfsense2.example.org]/root(1): route add 10.0.0.0/8 195.10.182.82 -interface vr0
    route: writing to routing socket: Network is unreachable
    add net 10.0.0.0: gateway 195.10.182.82: Network is unreachable
    [2.0.1-RELEASE][root@pfsense2.example.org]/root(2): route add 10.0.0.0/8 -interface vr0 195.10.182.82
    add net 10.0.0.0: gateway vr0
    [2.0.1-RELEASE][root@pfsense2.example.org]/root(3):

    Apparently the second form is correct.
    
    What does the routing table look like:
    

    [2.0.1-RELEASE][root@pfsense2.example.org]/root(4): netstat -r -n -f inet
    Routing tables

    Internet:
    Destination        Gateway            Flags    Refs      Use  Netif Expire
    default            192.168.211.173    UGS        0      383    vr0
    2.0.0.0&0xc30ab652 00:30:18:b0:19:85  US          0        0    vr0
    127.0.0.1          link#4            UH          0      210    lo0
    192.168.51.128/25  link#9            U          0        0 run0_w
    192.168.51.211    link#9            UHS        0        0    lo0
    192.168.211.128/25 link#3            U          0    39297    vr0
    192.168.211.173    00:30:18:b0:19:85  UHS        0    2278    vr0
    192.168.211.217    link#3            UHS        0        0    lo0
    192.168.217.0/24  link#2            U          0        0    rl0
    192.168.217.173    link#2            UHS        0        0    lo0

    
    Can I delete that route I added earlier?```
    
    [2.0.1-RELEASE][root@pfsense2.example.org]/root(9): route delete 10.0.0.0/8
    route: writing to routing socket: No such process
    delete net 10.0.0.0: not in table
    [2.0.1-RELEASE][root@pfsense2.example.org]/root(10): route delete 2.0.0.0/8
    route: writing to routing socket: No such process
    delete net 2.0.0.0: not in table
    [2.0.1-RELEASE][root@pfsense2.example.org]/root(11): route delete 10.0.0.0/8 -interface vr0 195.10.182.82
    route: writing to routing socket: No such process
    delete net 10.0.0.0: gateway vr0: not in table
    [2.0.1-RELEASE][root@pfsense2.example.org]/root(12): netstat -r -n -f inet
    Routing tables
    
    Internet:
    Destination        Gateway            Flags    Refs      Use  Netif Expire
    default            192.168.211.173    UGS         0      383    vr0
    2.0.0.0&0xc30ab652 00:30:18:b0:19:85  US          0       12    vr0
    127.0.0.1          link#4             UH          0      210    lo0
    192.168.51.128/25  link#9             U           0        0 run0_w
    192.168.51.211     link#9             UHS         0        0    lo0
    192.168.211.128/25 link#3             U           0    39719    vr0
    192.168.211.173    00:30:18:b0:19:85  UHS         0     2718    vr0
    192.168.211.217    link#3             UHS         0        0    lo0
    192.168.217.0/24   link#2             U           0        0    rl0
    192.168.217.173    link#2             UHS         0        0    lo0
    [2.0.1-RELEASE][root@pfsense2.example.org]/root(13): 
    
    ```Apparently not.
    
    Can I get some information about that strange 2.0.0.0 route?```
    
    [2.0.1-RELEASE][root@pfsense2.example.org]/root(13): route get default
       route to: default
    destination: default
           mask: default
        gateway: pfsense
      interface: vr0
          flags: <up,gateway,done,static>recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
           0         0         0         0      1500         1         0 
    [2.0.1-RELEASE][root@pfsense2.example.org]/root(14): route get 2.0.0.0
    route: writing to routing socket: No such process
    [2.0.1-RELEASE][root@pfsense2.example.org]/root(15): route get 10.0.0.0
    route: writing to routing socket: No such process
    [2.0.1-RELEASE][root@pfsense2.example.org]/root(16): route get
    route: writing to routing socket: Invalid argument
    [2.0.1-RELEASE][root@pfsense2.example.org]/root(17): route get 10.0.0.0/8
    route: writing to routing socket: No such process
    [2.0.1-RELEASE][root@pfsense2.example.org]/root(18): route get 10.0.0.0/8 -interface vr0 195.10.182.82
       route to: 10.0.0.0
    destination: ANantes-651-1-49-net.w2-0.abo.wanadoo.fr
           mask: 195.10.182.82
      interface: vr0
          flags: <up,done,static>recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
           0         0         0         0      1500         1         0 
    [2.0.1-RELEASE][root@pfsense2.example.org]/root(19):</up,done,static></up,gateway,done,static> 
    ```That is a strange network mask. A _nslookup_ of ANantes-651-1-49-net.w2-0.abo.wanadoo.fr returned 2.0.0.0 Probably I didn't get the command syntax correct. A subsequent re-reading of the route man page suggests the -interface option is intended for a point-to-point interface and there is no mechanism for specifying BOTH a gateway by IP address AND an interface to get to that gateway. I wonder how PPPoE deals with this?


  • I appreciate the time you have taken to look at this. If I get the wan ip to pfsense in a working fashion I'll let you know.



  • heres the routing table from the speedtouch:

    Administrator}[ip]=>rtlist
    abel                        Destination          Gateway  Interface    Mtc Sta
    us
                              10.0.0.138/32      127.0.0.1  loop          0  [UP

    10.0.0.255/32      127.0.0.1  loop          0  [UP

    46.31.205.68/32      127.0.0.1  loop          0  [UP

    127.0.0.1/32      127.0.0.1  loop          0  [UP

    192.168.1.254/32      127.0.0.1  loop          0  [UP

    192.168.1.255/32      127.0.0.1  loop          0  [UP

    255.255.255.255/32      127.0.0.1  loop          0  [UP

    from_46.31.204.160/32    192.168.1.0/24                  LocalNetwork  0  [UP

    195.10.125.82/32    46.31.205.68  Internet      0  UP

    46.31.200.20/32                  Internet      10  UP

    212.30.16.252/32                  Internet      10  UP

    10.0.0.0/24      10.0.0.138  LocalNetwork  0  [UP

    192.168.1.0/24  192.168.1.254  LocalNetwork  0  [UP

    0.0.0.0/0                  Internet      10  UP

    The gateway is not reachable when trying to ping when using the speetouch or my other netgear on their own yet internet works fine. How does that work if the gateway is not reachable?



  • Think I'll give up on this dhcp spoofing method, it seems linux based systems do have trouble dealing with it and I cannot use a modem in bridge mode due to being PPPoA. The vigor 120 makes this possible I think but I am not ready to purchase anything else at this stage.

    I may have found an alternative, PPPTP relay:  http://forums.whirlpool.net.au/archive/595905

    I have set the speedtouch up as stated but having trouble setting up the PPTP section on pfsense, can you please advise how this should be setup or if this should even work?

    The speedtouch has lan ip 10.0.0.38 and 192.168.1.254, one of which I think is a vlan.



  • @bilbo:

    I cannot use a modem in bridge mode due to being PPPoA.

    I don't know why you say that. As I wrote earlier, the document I downloaded describes using PPPoA on WAN side and PPPoE client on LAN side.



  • Can you provide a link to said doc please?





  • I could not see any info on how to get pppoa wan pppoe client working in the manual, also could not see any other instances of it working on the net.

    However  :) I seem to be up and running using the pptp relay! Wan is getting public ip and internet is accessible. tfg.


Log in to reply