Announcement

Collapse
No announcement yet.
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • How to Deploy Mobility if the customer does not have a DMZ

    How would I Deploy a Mobility router if the customer does not have a DMZ?

    Tell me if I am wrong. My first thought would be to just NAT to the E0 Port.

  • #2
    We use eth0 (default) for the internal port and eth1 for the remote access port which is NAT'd.

    Comment


    • #3
      Small warning with using NAT. We've seen the mobility router direct all the subnet traffic through itself as the "outside" interface was on the same subnet as the data network.

      Comment


      • #4
        You do need to have external users hit eth1, I tried without putting eth1 in a different subnet (ie eth0 and eth1 are in the same network with different IP addresses) and it doesn't work so we still ended up with a DMZ.

        Comment


        • #5
          A common network routing mistake is to assume that just because the packet came in a specific way, the return packet will go the same way.

          There is no "link" between the incoming packet and the outgoing packet and are routed based on the rules provided.

          When you throw 2 interfaces with ips on the same subnet, the device will receive the packets on the correct interface but will send OUT packets on its "default" gateway (assuming no other routes are defined)

          One crazy trick that im sure network admins will frown upon that MIGHT work is

          you set the NETMAKS of the server to 255.255.255.128 with one eth in the 192.168.0.1 - 192.168.0.126 (lets call it ETH0) range and another one in the 129-254 (lets call it ETH1) range.

          This trick will work if

          ALL your "local" hardware that need to talk to the server on the eth0 port is in the same subnet as the servers eth0 port (IE ip addresses between 1-126)

          AND

          The WAN router on the Eth1 subnet (ip address 129-254... if you want your wan to be .1 just flip the two ranges)

          You keep 255.255.255.0 on all other devices that way the rest of the devices can see each other no problem.

          ALL the devices think its one big /24 subnet so they talk to each other without a problem
          Server thinks its two /25 subnets and has to pick which way the packets go and since all routed packets need to go to the WAN router... This way you FAKE a second subnet.

          Note this trick will NOT work if you need rout packets over the eth0 to your wan router unless you assign the wan router an additional ip on the LAN network.

          Im not sure if it will work in this situation its just theory.

          **edit** you may want to make the LAN be the top part of the subnet so that you match up the broadcast ip of 192.168.0.255 with the real broadcast



          Last edited by darkdrgn2k; 05-29-2014, 04:44 AM.

          Comment


          • #6
            We deployed the SMR with only ETH0 Enabled. The only issue is that the SMR Web GUI was already using 443 so I had to use an alternate ssl port for client tunnels. I also enabled the Public NAT option under remote access. Seems to be working well for WiFi and 3G/4G Access. The atrernate SSL port is not a big deal since the provisioning assigns the correct ports. We will only run into an issue when using the mobile phones behind a firewall with egress outbound policies that do not allow traffic out on our alternate ssl port.

            If anyone knows how to change the Web GUI default SSL port number, please let me know. I'd much rather do that and use the standard SSL port for our mobile device tunnels...

            Thanks,

            Dan.

            Comment

            Working...
            X