Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Weaver]

[Moderator note. Certain posts have been split off from the Causing a resynch thread.]

Also, I would be happy to give you a hand configuring your firebrick to give you access to your modems.

@davec - your help would be very much appreciated, as would be that if other brick users. My existing configuration was working until I changed over to using vlans, so I don’t know if all that is required is to somehow update the description of sub-interfaces to modems’ admin i/fs to suit.

Another complication: I am pretty sure that Mrs Weaver and I randomly mixed up the modems so that now who knows which is plugged in to which port/VLAN. The modems all had distinct IP addresses. The type of config that I use requires each of the modems to be configured correctly for the slot (ie port) that it is plugged in to, and things won’t work otherwise.

This is a disadvantage compared to AA’s suggested example configuration for this (which doesn’t cater for VLANs). However I have the great advantages of not requiring you to use non-standard ports and being able to support any protocol, not just one TCP port. So I can support telnet too, but AA’s example is I think for http only.

I could not get SSH to work, something to do with the NATing I used in my config perhaps.

That would be one reason to not bother at all, and just use a second direct ethernet cable : that SSH would work. There is also the simplicity of it too.

[DaveC]

Weaver,

It may be a distraction, but it may also give you some ideas if I describe the way I've currently got my two modems (HG612s) set up.

Modem 1 - IP 10.x.x.201, LAN interface untagged, PPP packets tagged in VLAN 201
Modem 2 - IP 10.x.x.202, LAN interface untagged, PPP packets tagged in VLAN 202

(the HG612 allows you to VLAN-tag the PPP packets for VDSL (but NOT ADSL) - from a quick look at the user guide, I think the B10A allows similar, never tried the B10A though).

I then added static routes in both modems for my local LANs using 10.x.x.1 as the gateway.  The alternative to that would be to add a NAT rule in the Firebrick (to NAT from 10.x.x.1).

The modems are then connected to a VLAN-capable switch, and then to the Firebrick.

This all simplifies things in the Firebrick - I just need a single "WAN" interface with the IP 10.x.x.1 and all my modems are accessible.  I then use the "vlan" attribute in the "ppp" elements.


As for your configuration, if you're VLAN tagging the modem LANs, then yes, you'll need to add the appropriate "vlan=xxx" attributes to your "interface" elements (and then probably delete it from your "ppp" elements).   Maybe that's all that's needed if a similar configuration was working before.

[Weaver]

I can try that, indeed as you say it was working before. I have no idea how the reverse side worked exactly: by some miracle the Brick was just doing the right thing and NATing stuff going to the modems destined to 192.168.x.1 where x=1,2,3,4 per slot, but the source address the modem sees needed to be in the same 192.168.x.* range to make the modem happy, so n firewall rules were abused to rewrite the source address in a packet on its way to the modem. I don’t know whether that will hold up without change. See earlier thread somewhere.

I first will have to get the modems un-mixed up, as they will not respond anyway even if I get the config right now if they are all listening at the random wrong admin IP addresses and if so I will not know that I actually got things right.

[Should perhaps have asked that these last two posts be cut off and transferred to somewhere appropriate but can’t remember where just now.]

[DaveC]

Weaver,

The more you describe your setup, the more I think you just need to move the "vlan" attribute from your ppp element to the interface element (assuming that's what your current configuration looks like).

You only have a choice of 4 IPs, so you could just try all 4 on your first modem, to see if it works.  If so, then you have 3 to guess from for the second, and so on...

Dave.

[Weaver]

This is what I had (excerpts):

Firebrick XML snippets re modems' admin IP

<!--    ====================================================
   ** Modems’ admin **
   Management pseudo-‘interfaces’ to allow admin access to modems via http, telnet etc uses a sort of NAT and this breaks SSH currently.
   The modems’ admin interfaces are configured internally to be 192.168._xx_.1/24
   In each case the Brick itself has an address of .254 (see #_MDM_RETURN_NAT_254 ) on each mini-‘LAN’ that is the ethernet cable to a modem.
   This is so that the modem can reply to the Brick - the src addr has to be within the modem’s idea of the appropriate subnet range, which is a /24.
   Return traffic from the modem goes to the Brick at 192.168._xx_.254 and then gets NAT-rewritten to direct it onwards back to the original sender.
 -->
<!-- -->
<interface name="IF-PPP1" port="Port-WAN" vlan="101">
      <subnet ip="192.168.1.254/24"/>
</interface>
<interface name="IF-PPP2" port="Port-WAN" vlan="102">
      <subnet ip="192.168.2.254/24"/>
</interface>
<interface name="IF-PPP3" port="Port-WAN" vlan="103">
      <subnet ip="192.168.3.254/24"/>
</interface>
<interface name="IF-PPP4" port="Port-WAN" vlan="104">
      <subnet ip="192.168.4.254/24"/>
</interface>
<!-- == see also ‘firewall’ rules below which make return traffic work by NATing - see ##_MDM-REVERSE-NAT -->

<!-- == Modem admin interface helper NAT rules: ‘firewall’ rules which make return traffic work by NATing
   See also above ##_MDM-REVERSE-NAT
   The address .254 must match that earlier - see #_MDM_RETURN_NAT_254 and the interface names have to match
   Return traffic from the modem goes to the Brick at 192.168._xx_.254 and then gets NAT-rewritten to direct it onwards back to the original sender.
-->
<!-- -->
<rule-set name="Modem 1 admin NAT" target-interface="IF-PPP1" no-match-action="continue">
      <rule set-source-ip="192.168.1.254" set-nat="true"/>
</rule-set>
<rule-set name="Modem 2 admin NAT" target-interface="IF-PPP2" no-match-action="continue">
      <rule set-source-ip="192.168.2.254"/>
</rule-set>
<rule-set name="Modem 3 admin NAT" target-interface="IF-PPP3" no-match-action="continue">
      <rule set-source-ip="192.168.3.254"/>
</rule-set>
<rule-set name="Modem 4 admin NAT" target-interface="IF-PPP4" no-match-action="continue">
      <rule set-source-ip="192.168.4.254"/>
</rule-set>

<!-- [[• § • ~~~~~~~~~~~~~~~~            ~~~ Speeds calculated at 2018-09-14T04:27:27 (UTC), modem=ZyXEL VMG1312-B10A custom firmware MTU 1508; line=BT 21CN ADSL2; PPPoEoA; using protocol efficiency factor = 0.8844339622642 ~~~ -->
<ppp name="PPP1" port="Port-WAN" vlan="101" username="cwcc@a.1" password="whatever" graph="Graph-PPP1" mtu="1500" speed="441818" comment="Upstream sync speed=515k, modem load factor=97%. Speeds calculated at 2018-09-14T04:27:27 (UTC), modem=ZyXEL VMG1312-B10A custom firmware MTU 1508; line=BT 21CN ADSL2; PPPoEoA; using protocol efficiency factor = 0.8844339622642"/>
<ppp name="PPP2" port="Port-WAN" vlan="102" username="cwcc@a.2" password="whatever" graph="Graph-PPP2" mtu="1500" speed="458977" comment="Upstream sync speed=535k, modem load factor=97%"/>
<ppp name="PPP3" port="Port-WAN" vlan="103" username="cwcc@a.3" password="whatever" graph="Graph-PPP3" mtu="1500" speed="373186" comment="Upstream sync speed=435k, modem load factor=97%"/>
<ppp name="PPP4" port="Port-WAN" vlan="104" username="cwcc@a.4" password="whatever" graph="Graph-PPP4" mtu="1500" speed="387771" comment="Upstream sync speed=452k, modem load factor=97%"/>
<!-- -->

Maybe it simply appeared that it wasn’t working, because the modems’ IP addresses were swapped around, as I mentioned before. Can soon test that.

[DaveC]

That all looks fine to me - good luck!

[Weaver]

I am pretty sure that the modems are merely all swapped around or programmed to use the wrong admin IP addresses. A bit of systematic fiddling around and I found the modems were
Slot #1 - 192.168.1.1 - ok
Slot #2 - 192.168.3.1 - swapped
Slot #3 - 192.168.2.1 - swapped
Slot #4 - 192.168.1.1 - programmes wrongly

[DaveC]

Does that mean you can access them through the firebrick now?

[Weaver]

I have now fixed the problem completely. Just need to clean up the situation with the modems finally. Two modems - #2 and #3 need swapping over, as seen from the table earlier and the #4 one needs reconfiguration correctly.

[Weaver]

I have now managed to log in to each one in turn.