Print

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

[burakkucat]

I am very pleased to see that result as, logically, it had to be possible to achieve. 

As for what the Firebrick is actually doing . . . my head just spins, wildly, when thinking about it. 

Perhaps you could show the configuration details to Ixel, in private, and ask if he would be willing to review your current configuration?

[DaveC]

Hi,

Regarding the interface to the modems, there are various ways you could do it, but here are the relevant extracts from my A&A-provided "Office::1" configured firebrick:

First, define the three interfaces, and (important!) put each in its own routing table:

Code: [Select]

<interface name="Modem_1"
            port="WAN1"
            table="1"
            comment="Interface to get to Modem 1">
  <subnet ip="192.168.1.33/24"/>
 </interface>
 <interface name="Modem_2"
            port="WAN2"
            table="2"
            comment="Interface to get to Modem 2">
  <subnet ip="192.168.1.33/24"/>
 </interface>
 <interface name="Modem_3"
            port="WAN3"
            table="3"
            comment="Interface to get to Modem 3">
  <subnet ip="192.168.1.33/24"/>
 </interface>

Note that the IP addresses should be the same for all the interfaces - the trick is to put them in their own routing tables.

You then need the following rule-set to access the modems using port-forwarding:

Code: [Select]

<rule-set name="Modems"
           source-ip="[IP addresses you want to access the modems from]"
           target-ip="[IP address of your firebrick]"
           target-port="81-83"
           no-match-action="continue">
  <rule name="Modem_1"
        target-port="81"
        set-source-ip="192.168.1.33"
        set-nat="true"
        set-target-ip="192.168.1.1"
        set-target-port="80"
        set-table="1"
        action="accept"
        comment="Get to Modem 1"/>
  <rule name="Modem_2"
        target-port="82"
        set-source-ip="192.168.1.33"
        set-nat="true"
        set-target-ip="192.168.1.1"
        set-target-port="80"
        set-table="2"
        action="accept"
        comment="Get to Modem 2"/>
  <rule name="Modem_3"
        target-port="83"
        set-source-ip="192.168.1.33"
        set-nat="true"
        set-target-ip="192.168.1.1"
        set-target-port="80"
        set-table="3"
        action="accept"
        comment="Get to Modem 3"/>
 </rule-set>

You can then access the modems at the following URLs:

Code: [Select]

http://ip-address-of-brick:81/
http://ip-address-of-brick:82/
http://ip-address-of-brick:83/


[Weaver]

For the benefit of all, the secret is the following group of additional xml config elements

<interface name="IF-MdmAdm1" port="Port-WAN1"> <!-- phys port 2, to which ppp1 is connected -->
      <subnet ip="192.168.1.254/24"/>
</interface>
<interface name="IF-MdmAdm2" port="Port-WAN2"> <!-- phys port 3, to which ppp2 is connected -->
      <subnet ip="192.168.2.254/24"/>
</interface>
<interface name="IF-MdmAdm3" port="Port-WAN3"> <!-- phys port 4, to which ppp3 is connected -->
      <subnet ip="192.168.3.254/24"/>
</interface>
<rule-set name="Modem 1 admin NAT" target-interface="IF-MdmAdm1" no-match-action="continue">
      <rule set-source-ip="192.168.1.254"/>
</rule-set>
<rule-set name="Modem 2 admin NAT" target-interface="IF-MdmAdm2" no-match-action="continue">
      <rule set-source-ip="192.168.2.254"/>
</rule-set>
<rule-set name="Modem 3 admin NAT" target-interface="IF-MdmAdm3" no-match-action="continue">
      <rule set-source-ip="192.168.3.254"/>
</rule-set>

The above rules have all been added.

The whole config is very very long and has extremely longwinded copious comments in it since my memory is shot. I would be happy to post the whole thing though. Mind you, someone will tick me off ;-) for exposing IP addresses.

As mentioned before, the main LAN lives at IPv4 81.187.x.y/26 (no RFC1918, no NAT of any sort). The additional subnet objects set up addresses for the Firebrick of 192.168.n.254 on ethernet link (n+1) to each modem.

A ‘rule set’ is an entry-if-condition (match condition) plus zero or more rules plus an action to be taken if the entry condition is not met. Each of the rules inside it can have an if-match-condition of its own (not used in this case) and an action. The kind of action can be the usual firewall things but in addition it can modify packets, set up stateful flow (‘connection’) tracking, set up NAT table entries, place traffic flows under the control of speed shaper objects for rate limiting and probably other things that I forget.

If I had not been so full of drugs it might not have taken me seven years to work out how to do this. At one time it would probably have taken about ten minutes.

[Weaver]

I seem to have ended up with a subject split across two threads here

DaveC thank you so much, you are a star. There is absolutely no chance that I would ever have worked that out. I have absolutely no idea what the concept of multiple routing tables even means!

This solution has the advantage that it means I don't have to reconfigure individual modems. If one dies and a new one gets swapped in then it will be administratively visible even without any changes made to it.

The AA solution has the disadvantages that (i) it only covers TCP port 80, so no telnet or icmp for example, and (ii) it is longer and more complex.

[DaveC]

Hi,

Telnet uses port 23, so you could copy that entire rule-set to do a similar trick to forward requests for telnet (http is port 80 - so replace 80 in the rules with 23, and replace 81-83 with your own choice of ports - e.g. 231-233).  You'll then need your telnet client to connect to ports 231, 232 or 233 on your brick's IP address instead of the default (23).

Not sure about ICMP, but also not sure why you would need to.

And yes, as you said, I'm sure this is why A&A do it this way - all modems having an identical config makes it easy to swap over hardware when testing for faults.  In fact I did that very thing this morning...

Dave.

[Weaver]

Of course you're right about the telnet solution, but it doesn't scale in admin terms, it just means more and more rules.

I suggested ICMP because one might want to ping or traceroute to a modem for debugging purposes or to check that a modem is up.

[Ixel]

Just checking this thread, interesting stuff. Glad to hear you worked it out. When I return to using the DrayTek/Fritz!Box later on I'll also be doing something similar, except most of my LAN devices are on 192.168.1.x/24. Only a few devices share a /29 public IP from AAISP, I didn't ask for a bigger subnet, assuming they offer one, as A) I felt I might be being greedy for it just being mostly some laptops and desktop PC's or such and B) I have enough public IP's for my home server, NAS, and a few virtual machines running various other stuff.

[Weaver]

I've had a thought, I suppose that I could use the other method, which AA uses, but without rewriting ports, remapping IP addresses instead so as to allow the modems themselves to stay at their standard config?

So basically I send to say 192.168.2.1 and rewrite that as a destination of 192.168.1.1. I also have to do something about the return path, unless the brick intelligently takes care of that automatically.

[Weaver]

I had a go at the address-rewriting thing. As an initial test I successfully rewrote a modem’s address so I could access 192.168.2.10 even though the modem was really at 192.168.2.1. But when, following on from the success of this, I changed the modem back to its default of 192.168.1.1 I then lost access to it even after changing the rewriting rules accordingly. No mattter what I did, I could not access it again. So I will have to ask Mrs Weaver to power-cycle it for me and then try and find out where it is hiding.

[burakkucat]

I have just found another of your threads on the subject of modem access from the Firebrick, dating from early 2016, and so note it here, for completeness.

[Weaver]

I regained access to the lost modem - I realised I had to now add a reverse-path rule too, the second rule below

   <rule-set name="Modem 2 admin NAT" target-interface="IF-MdmAdm2" no-match-action="continue">
      <rule set-source-ip="192.168.1.254" set-target-ip="192.168.1.1"/>
   </rule-set>
   <rule-set name="Modem 2 admin NAT reverse" source-ip="192.168.1.1" source-interface="IF-MdmAdm2" no-match-action="continue">
      <rule set-target-ip="192.168.2.1"/>
   </rule-set>

whereas before when I was not moving to a different /24 the thing was intelligently just working without the second rule. The set-target-ip was the first change.

So now I don't have to reconfigure modems and keep them assigned to the correct port, they can all have identical config and so swap outs are much quicker.

[burakkucat]

So now I don't have to reconfigure modems and keep them assigned to the correct port, they can all have identical config and so swap outs are much quicker.

Well done. Thank you for documenting it.

This current effort will clearly pay dividends at a later date.

[Weaver]

I spoke too soon. When I repeated the above change for the next modem, it all fell apart, nothing worked after that, possibly something to do with confusing the routing rattles and hence the set-table multiple routing tables directives in the AA solution contributed by my fellow kitizen. I will have to adapt that AA solution, god knows what it all means though, if I want to go further.

So for the moment it is back to distinctly configured modems and the original simpler single rewrite rules, not pairs.

[Weaver]

I had so completely lost track of that thread from two years ago, with generous earlier contributions from many others, to whom go my thanks. This is the effect of the pain drugs, history just getting wiped out, no memory at all, especially for things that happened a couple of seconds earlier.


Thanks to Burakkucat for spotting that thread.