Das Problem wird wahrscheinlich im Routing bestehen. Das Modem berücksichtigt und erlaubt kein Standardgateway. Nur wenn sich der Client im gleichen Netzsegment befindet, hat man eine Chance für den Zugriff.
Eben ... der einzige Client, der sich in demselben Netzsegment befindet (die DSL-Seite mal nicht berücksichtigt, da müssen die Daten erst noch durch die Modulation - das ist im OSI-Modell etwas Mischmasch aus L1/L2), ist die FRITZ!Box. Selbst wenn das Modem seinerseits das Ziel der Kommunikation mittels ARP-Request auflösen sollte, "sieht" es doch nur das externe Interface der FRITZ!Box und wenn es dort eine reine Ethernet-Verbindung geben sollte, dann muß die auch antworten auf einen derartigen Request. Spätestens damit weiß das Modem, wohin die Pakete auf L2 zu adressieren sind und sie kommen bei der Box an, die dann den Rest (NAT - die passende ausgehende Verbindung kommt ja von irgendjemandem im LAN) übernimmt.
Aber man braucht ja nicht zu spekulieren ... die aktuelle Konfiguration (wer macht PPPoE, getaggte Pakete ja/nein) steht in den Support-Daten und spätestens der Paketmitschnitt offenbart, ob auf dem externen Interface (1. Internetverbindung) die Pakete mit oder ohne PPP-Header unterwegs sind und schon die Frage, ob irgendwelche Zugangsdaten im Modem eingetragen sind, sollte darüber Aufschluß geben, ob das Modem selbst PPPoE macht und die Pakete eher mit oder ohne PPP-Header auf seiner Ethernet-Schnittstelle bereitstellt.
Ich habe jedenfalls noch keine Kombination gesehen, wo ein Modem (eines mit GUI jedenfalls) vor einer FRITZ!Box nicht erreichbar gewesen wäre ... es ergäbe auch netzwerktechnisch für mich keinen Sinn. Wie sollte das Modem eine FRITZ!Box und ein beliebiges anderes Gerät unterscheiden - solange da eine Konfiguration über HTTP-Zugriff erfolgt und nicht mit irgendeinem windigen Programm, was das direkt auf L2 löst (und dann meistens wieder Windows beim Anwender voraussetzt). Das wäre zwar bei anderen L2-Geräten (streng genommen ist das Modem auch eines) denkbar, hier gibt es aber ein GUI und sogar ein CLI und die können beide nur schlecht ohne L3/L4 arbeiten, also ist das Gerät beim Management-Zugriff da sicherlich nicht transparent.
Ein Modem, welches sein GUI/CLI auch auf seinem eigenen WAN-Interface bereitstellt (eine IP-Adresse sollte es als reines Modem dort gar nicht haben, die öffentliche IP-Adresse hat ja der nachgelagerte Router), wäre wieder ein leichtes Ziel für Angriffe - und (in meinen Augen zumindest) ein schwerer Fehler der betreffenden Firmware. Solange es das nicht macht, kann das Management eigentlich nur über eine einzelne Schnittstelle erfolgen (außer es gibt eine gesonderte dafür) und es bräuchte nicht einmal ARP-Requests seitens des Modems vor dem Senden ... das kann ganz einfach an die MAC-Adresse zurücksenden, von der das Paket kam.