• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
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 Oct 20, 2007, 4:59 PM

    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
    • C
      Cry Havok
      last edited by Oct 20, 2007, 6:23 PM

      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 Oct 20, 2007, 7:24 PM Oct 20, 2007, 7:15 PM

        @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
        • J
          jahonix
          last edited by Oct 21, 2007, 10:17 PM

          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 Oct 23, 2007, 11:56 AM Oct 23, 2007, 11:47 AM

            @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
            • J
              jahonix
              last edited by Oct 23, 2007, 11:53 PM

              @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 Oct 25, 2007, 2:26 AM

                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
                • J
                  jahonix
                  last edited by Oct 29, 2007, 6:34 PM

                  Glad you're here!  ;)

                  1 Reply Last reply Reply Quote 0
                  8 out of 8
                  • First post
                    8/8
                    Last post
                  Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                    This community forum collects and processes your personal information.
                    consent.not_received