Print

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

[aesmith]

Just had a quick browse of the Firebrick manual - do I detect a touch of the A&A "NAT is Evil" viewpoint?

Anyway I was considering not the path from your devices to the modem, but the return.  Let's say your device was x.x.x.x/26, and the D-Link modem has it's default IP settings of 192.168.1.1/24 and just for illustration we've configured the FB interface as 192.168.1.2.   The Firebrick will see both these subnets as directly attached, and from what you say it will route between them without explicit configuration.   So your packet from x.x.x.x will reach the modem, but how does the modem know how to route back to x.x.x.x?   What I'm suggesting is to NAT your source address, so that the packet hitting the modem appears to originate from 192.168.1.2, which is on the modem's local subnet and therefore reachable directly.   Does that make sense?   

In Cisco terms (sorry) you'd mark your LAN as "inside", the interface to the modem as "outside", then you'd configure inside source nat.

If you can configure the modem (in this example) with a default gateway of 192.168.1.2 then NAT is not required and it's just plain old routing.

[Weaver]

> how does the modem know how to route back to x.x.x.x?   
Absolutely, I don't think it does. That snippet given to me was part 2 of 3 if my understanding is correct.

>What I'm suggesting is to NAT your source address, so that the packet hitting the modem appears to originate from 192.168.1.2, which is on the modem's local subnet and therefore reachable directly. Does that make sense?   

That solves the problem of the modem not knowing what its default gateway is. But surely more NAT would be needed to map the returning packet from the modem to an accessible public IP, not in RFC1918. Which I could do if I can work out how.

I also have no clue what table 1 is in the first snippet.

[Weaver]

I could just ask RevK to do it for me. Because I am completely and utterly out if my depth. I need to work out s plan for security testing in the result. An I probably ought to set strong passwords on the modems but really I don't want to as I would have to remember somehow to make sure this is done on a swapout when I am in a panic anyway after a lightning strike. It would be better to not have to be relying on passwords, by firewalling access to the modems so that the whole LAN is not allowed to see them, just selected IPs. Maybe that's a hole in itself as knowledge of the sacred IP lets you in. Perhaps I'm stuck with passwords anyway or perhaps doing both is the best way.

I'd like to set up a monitoring device if I can get this to work. It ought to be a Raspberry Pi, I am so desperate for an excuse. 

[aesmith]

That solves the problem of the modem not knowing what its default gateway is. But surely more NAT would be needed to map the returning packet from the modem to an accessible public IP, not in RFC1918. Which I could do if I can work out how.

Caveat - lack of specific Firebrick knowledge.  However I've never seen any form of NAT that didn't match the reply traffic and apply appropriate translation.  I think that's the only way that dynamic NAT and especially port translation could work.  So assuming the FB is at least halfway normal, the paths would be ..

Oubound
      Host sends ... src=x.x.x.x dst=192.168.1.1
  Modem receives ... src=192.168.1.2 dst=192.168.1.1
Return
    Modem sends ... src=192.168.1.1 dst=192.168.1.2
  Host receives ... src=192.168.1.1 dst=x.x.x.x

I don't see a security issue, only packets destined for 192.168.1.1 will get to the modem, and they can't traverse the Internet.  For belt and braces you could apply a rule that only permitted your source subnet to send to the modem, and only permits the modems to talk to your subnet in return.  However I can't see that's needed. 

[Weaver]

Tony, in your example below, how would we generalise that to three modems? It's unclear how the firebrick would know which 192.268.1.1 is which, unless we do an additional something earlier.

[aesmith]

The other two modems would need to have their IP addresses changed so that there are three separate Firebrick to Modem subnets.   What I'd suggest is going ahead with just one in the first place to prove it all works, and that one might as well stay on it's default settings.   If it all works I'd configure the three modems, then configure your spare onto a fourth subnet, then it can replace either of the three with only Firebrick changes needed to reinstate management access.

[Weaver]

Is there a way to do it without changing the management i/f IP of each modem? Could we be a little more creative with more use of NAT ?

[aesmith]

I wouldn't think there'd be a way for the Firebrick to have the same address visible on different interfaces.  Ultimately the physical interface of the FB needs to have an address on the D-Link's subnet.   I thought I had an idea, but it fell to pieces when I thought it through.

[Weaver]

> Ultimately the physical interface of the FB needs to have an address on the D-Link's subnet.
True, but could we rewrite the source address of packets coming from 192.268.1.1 differently in each subnet? I'm not sure there's a way to that because I don't know how you would specify it.

Mind you, if you define 'interfaces', then you can specify the name of the interface as an attribute to match against in a firewall rule. Then you could make rules that don't apply to multiple modems.

[burakkucat]

Just throwing an idea up into the air and seeing how it lands . . . 

If you do not want to change the IPv4 address of the management interface of the three D-Link modems, would it be possible to specify which modem to be addressed by its hardware MAC?

Granted, if/when you need to swap out a zapped/fried modem for a new one (from your stock cupboard), you would need to note its hardware MAC (from the label on the bottom of the modem) and enter that value into the appropriate line of your FireBrick's configuration file.

[Weaver]

Burakkucat, you can have rules with a MAC address attribute match, but as you said, it would make swapouts a nightmare. I would need to keep the process of modem swapout simple. For  example: when I am in hospital, Mrs Weaver can just take a modem, preconfigured by Andrews and Arnold to be a modem only, straight from the spare kit shelf and stick it in in place of one tweaked by lightning.

[burakkucat]

Nods in acknowledgement.