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

    How to connect to modem's web interface?

    Scheduled Pinned Locked Moved Problems Installing or Upgrading pfSense Software
    8 Posts 3 Posters 12.6k 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.
    • J
      JackTripper
      last edited by

      My modem has a web interface. It's handy because i can see if it's actually connected or not, line noise, error rates, etc.

      If i connect the modem to my destop PC (rather than to the pfSense PC), i can ping and browse the modem's web interface fine. The modem's IP is 192.168.0.254, and listens on port 8080. i also can packet trace the activity from my PC:

      Pinging modem

      | ARP REQ | Phalanx => Broadcast | 192.168.0.98 -?- 192.168.0.254 |
      | ARP RESP | Phalanx <= Ovislink_LAN | 192.168.0.254 -!- 192.168.0.98 |
      | IP/ICMP | Phalanx => Ovislink_LAN | 192.168.0.98 => 192.168.0.254 | ECHO |
      | IP/ICMP | Phalanx <= Ovislink_LAN | 192.168.0.98 <= 192.168.0.254 | ECHOREPLY |

      You can see my machine doing an ARP broadcast, asking for the MAC address of the modem (the Ovislink). The modem responds with it's IP, the echo goes out, and i get a reply. Similar detail can be seen when i connect to the web port of the modem:

      Connecting to web port 8080

      | ARP REQ | Phalanx => Broadcast | 192.168.0.98 -?- 192.168.0.254 |
      | ARP RESP | Phalanx <= Ovislink_LAN | 192.168.0.254 -!- 192.168.0.98 |
      | IP/TCP | Phalanx => Ovislink_LAN | 192.168.0.98:50001 => 192.168.0.254:8080 | SYN |
      | IP/TCP | Plalanx <= Ovislink_LAN | 192.168.0.98:50001 <= 192.168.0.254:8080 | SYNACK |
      | IP/TCP | Phalanx => Ovislink_LAN | 192.168.0.98:50001 => 192.168.0.254:8080 | ACK |

      After the ARP request, a TCP connection is established with the normal SYN, SYN ACK, ACK process. And all is well.


      Now, rather than connecting the modem to my desktop PC, i connect it to the PC that is running pfSense.

      Note: Previously, i had changed pfSense's LAN IP Address to be 192.168.1.1/16, rather than 192.168.1.1/24. This is because my network was already 192.168.0.0/16.

      First thing i do is disable the "Block private networks" feature under Interfaces->WAN, since my modem's LAN interface is running as 192.168.0.254. This removes the first firewall entry under Firewall->Rules that was blocking all RFC1918 traffic. Next i added a firewall rule:

      Action: Pass
      Interface: WAN
      Protocol: TCP
      Source: Single host or alias  192.168.0.254
      Destination: LAN subnet
      Destination Port Range: any
      Log Packets: Yes
      Description: ADSL Modem

      After saving and applying my changes i tried using the Diagnostics->Ping feature to ping 192.168.0.254 on the WAN side. It, of course, didn't work.

      i thought about it, and it seems to me that i can't just allow TCP packets in on the WAN from 192.168.0.254, i also need to allow ARP response packets (how else could pfSense find the MAC address of the hardware it's trying to send an IP packet to?). It also occurred to me that i can't say LAN as the destination, because it's actually the WAN interface that's pinging. So i updated the firewall rule to:

      Action: Pass
      Interface: WAN
      Protocol: any
      Source: Single host or alias  192.168.0.254
      Destination: any
      Destination Port Range: any
      Log Packets: Yes
      Description: ADSL Modem

      Now when i ping it…doesn't work. No real surprise there.  So i decided to run a packet trace:

      Interface: WAN
      Host Address: 192.168.0.254
      Count: 1
      Level of Detail: Full

      i started the trace, did a ping from Diagnostics->Ping, and get…nothing. No ping reply, and no packets in the trace.

      So now it occurs to me that just because pfSense is on the 192.168.1.1/16 subet, and my desktop is on the 192.168.0.98/16 subnet, and my server is on the 192.168.0.10/16 submet: maybe the modem is not on the /16 subnet. i plug the modem back into my desktop, connect to the web interface and see that it's set for 192.168.0.254/24. So i reconfigure the modem for 192.168.1.254/24. i then reconfigure my desktop to be 192.168.1.98, the server to be 192.168.1.10, and now the modem is 192.168.1.254 in addition to pfSense being 192.168.1.1.

      i reconnect the modem to the pfSense box, try to ping it and i get...no reponse.  i do a packet trace for packets from 192.168.1.254 and i see...none.

      So now i'm stumped, and am asking for help.

      1 Reply Last reply Reply Quote 0
      • Cry HavokC
        Cry Havok
        last edited by

        You need to move from /16 to /24, or different IP ranges.  At the moment your arrangement will never work as pfSense believes that the IP of the modem is on the LAN side since it's in the LAN subnet (192.168/16).

        1 Reply Last reply Reply Quote 0
        • J
          JackTripper
          last edited by

          @Cry:

          You need to move from /16 to /24, or different IP ranges.  At the moment your arrangement will never work as pfSense believes that the IP of the modem is on the LAN side since it's in the LAN subnet (192.168/16).

          Would a static route for 192.168.1.254 mask 255.255.255.255 be needed to fix that?

          Anyway, i moved pfSense to 192.168.1.1/25. This means that the addresses 192.168.1.0-127 are in it's LAN subnet.

          The ping still doesn't work, but at least now in the WAN packet capture i see:
          IP 216.8.135.102 > 192.168.1.254: ICMP echo request, id 4942, seq 0, length 64
          IP 216.8.135.102 > 192.168.1.254: ICMP echo request, id 4942, seq 1, length 64
          IP 216.8.135.102 > 192.168.1.254: ICMP echo request, id 4942, seq 2, length 64

          i'm not seeing anything in the firewall dropping ICMP packets from 192.168.1.254, nor am i seeing any packets logged against my "DSL Modem" firewall rule. So there just must not be any echo replies coming back to be either blocked or passed.

          No echo replies must mean that no echo requests are going out.  What can still be going wrong?


          Although, i think i know what it is…and i think i'm screwed.

          i noticed in the packet capture (on the WAN side) that i'm not seeing any PPPoE protocol packets. They're all TCP, UDP, ICMP, etc.  This must mean that the WAN capture isn't showing me a capture of the WAN interface, but instead is showing a capture of what's inside the PPPoE traffic packets.

          i want to send a ICMP ping packet out the WAN ethernet interface, but instead it must be wrapping the ICMP packet into a PPPoE packet and sending it out the PPPoE interface. Of course the modem doesn't respond, because it doesn't see an ICMP packet, it only sees a PPPoE packet, and sends it out over the telephone lines.  When my ISP unwraps the packet, it drops the packet because it's destined for 192.x.x.x.

          i assume that Windows can do it because it decides that because the packet is destined for the local network - it dumps it on the wire without wrapping it in a PPPoE packet, and sending it to the modem's LAN side MAC address.

          That's what it is, isn't it?

          1 Reply Last reply Reply Quote 0
          • jahonixJ
            jahonix
            last edited by

            Look at this thread:
            http://forum.pfsense.org/index.php/topic,5727.msg34562.html#msg34562

            Accessing a modem in front of your pfSense's WAN in PPPoE mode was discussed already.
            The search function of this forum is working really well - if you try it…

            1 Reply Last reply Reply Quote 0
            • J
              JackTripper
              last edited by

              @jahonix:

              Look at this thread:
              http://forum.pfsense.org/index.php/topic,5727.msg34562.html#msg34562

              i entered:
              pkg_add -r redir
              ifconfig xl0 192.168.1.254/32
              redir –lport 8080 --cport 8080 --caddr 192.168.1.254 &

              But the first line gives an error
              $ pkg_add -r redir
              Error: FTP Unable to get ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-6.2-release/Latest/redir.tbz: File unavailable (e.g., file not found, no access)

              and it doesn't work. Although, the pfSense ping tool can ping 192.168.254 (but i see nothing in the pfSense packet capture).

              Oddly, my desktop machine can now ping the modem:
              Pinging modem from internal LAN

              | Protocol | MAC Addresses | IP Addresses |
              | IP/ICMP | Phalanx => pfSense_LAN | 192.168.1.1 => 192.168.1.254 |
              | IP/ICMP | Phalanx <= pfSense_LAN | 192.168.1.1 <= 192.168.1.254 |

              But i cannot connect to the web interface, either when trying to
              connect to port 8080 on the modem's IP:

              | Protocol | MAC Addresses | IP Addresses |
              | IP/TCP | Phalanx => pfSense_LAN | 192.168.1.1:62278 => 192.168.1.254:8080 | SYN |

              Or when trying to connect to
              port 8080 on pfSense's LAN IP:

              | Protocol | MAC Addresses | IP Addresses |
              | IP/TCP | Phalanx => pfSense_LAN | 192.168.1.1:62278 => 192.168.1.1:8080 | SYN |

              i assume that redir should handle either?


              Let me ask this another way. Why isn't a static route enough to do what i want? i would have through a static route of:
              Network: LAN
              Destination: 192.168.1.254/32
              Gateway: MAC address of WAN card

              What problems does this not take care of? Is it because there's no way to add a firewall rule that allows all traffic from a MAC address - and then pfSense wouldn't be able to ARP the modem? Does firewall rules even deal with ARP packets? Would a simple static route not work because things have to also then be NATed, and wouldn't be?

              What are your thought processes about what is and is not going on here?

              1 Reply Last reply Reply Quote 0
              • jahonixJ
                jahonix
                last edited by

                @JackTripper:

                $ pkg_add -r redir
                Error: FTP Unable to get ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-6.2-release/Latest/redir.tbz: File unavailable (e.g., file not found, no access)

                and it doesn't work.

                It does work over here:

                pkg_add -r redir

                Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-6.2-release/Latest/redir.tbz… Done.

                But your pfSense must be able to reach out via WAN interface to fetch this.

                @JackTripper:

                Let me ask this another way. Why isn't a static route enough to do what i want? i would have through a static route of:
                Network: LAN
                Destination: 192.168.1.254/32
                Gateway: MAC address of WAN card

                What problems does this not take care of?

                Everything you send out through the WAN if gets encapsulated in PPPoE and sent to your ISP's gateway. This way you cannot reach a network in front of your WAN other than your ISP. It would work if the modem does the PPPoE and you have a LAN subnet between them. But I wouldn't wanna do that - at least not any more. ;D

                1 Reply Last reply Reply Quote 0
                • J
                  JackTripper
                  last edited by

                  It would work if the modem does the PPPoE and you have a LAN subnet between them. But I wouldn't wanna do that - at least not any more. ;D

                  If i wanted to do that i wouldn't be using pfSense.

                  1 Reply Last reply Reply Quote 0
                  • jahonixJ
                    jahonix
                    last edited by

                    Glad you're here!  ;)

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