Advanced In Home Routing Issue
mtntrailseeker

MI424WR-GEN2 REV E connected via coax to the ONT.

I'm having problems "now" with additional network devices and routes behind this device. For several months this environment has worked fine, since January in fact when I had FiOS installed and configured this device

The other day I needed to add another network scope, ran into issues of it not working and decided to reset to default the MI424 and reconfigure. After that, the one scope (168.50.0/24) that had worked, no longer works as well as the one I was trying to add. Then discovered that the backup that I had made several months ago cant be restored. The human readable config gives me an error for some reason.

The topology is as follows. Connected to one of the ethernet ports on the MI424 is a switch and behind it is another routing device with one interface at 192.168.1.15 and behind it is the 192.168.50.0/24 network.

The MI424 dhcp server for devices begins at 192.168.1.34-39 so there is no conflict with using address between 192.168.1.2-33.

I have a static route configured on the the MI424 as follows:

Routing Table
Name Destination Gateway Netmask Metric Status Action
Network (Home/Office) 192.168.50.0 192.168.1.15 255.255.255.0 1 Applied

From the diagnostics page on the MI424 i can successfully ping the 50.1 GW address as well as a host behind it. The host can ping the MI424 GW address of 192.168.1.1 which tells me my static route is fine and if I remove it this no longer works.

The 50.1 device and the hosts behind it cannot ping through the MI424 to the internet. Firewall on the MI424 is set to minimum.

Other computer devices in the 192.168.1.34-39 range have no issue accessing the internet.

Going NUTS in CA..

0 Likes
Re: Advanced In Home Routing Issue
lasagna
Community Leader
Community Leader

This sounds like the NAT rule on the ActionTec isn't firing for those network addresses which are not on the directly attached subnet.  Essentially passing the traffic thru the ActionTec with it's original source address intact.   Can you turn on the security logging (Firewall -> Security Log -> Settings) and check all the boxes and see if maybe you can spot an error message which might confirm this theory?   Optionally, you would need someone with a public facing internet address who can run a packet trace and tell you what they are seeing as the source IP address from the systems on the routed network (if the NAT isn't firing, then the source addresses will be the 192.168.50.x address -- which of course is not valid once it reaches the internet side of the router and thus the receiving host can't find it's way home).

0 Likes
Re: Advanced In Home Routing Issue
mtntrailseeker

I agree with the assessment on NAT.

Below is the log with attempted pings sourced from my device behind the switch.  I don't see anything being blocked message wise.

I've been trying to find documentation for the WI424 for advanced filtering and more importantly the logs but have come up empty except for the "lightweight" user manual you can download from VZ.

Let me know if you have any insight.

Time Event Event-Type Details

Sep 20 13:28:26 2010 Outbound Traffic Connection closed : ICMP 192.168.50.1 10885 <-->192.168.50.1 10887 [98.137.149.56] type 8, trk 3 clink1 Null-NAPT Outgoing

Sep 20 13:28:25 2010 Outbound Traffic Connection closed : ICMP 192.168.50.1 10885 <-->192.168.50.1 10886 [98.137.149.56] type 8, trk 2 clink1 Null-NAPT Outgoing

Sep 20 13:28:24 2010 Outbound Traffic Connection closed : ICMP 192.168.50.1 10885 <-->192.168.50.1 10885 [98.137.149.56] type 8, trk 1 clink1 Null-NAPT Outgoing

Sep 20 13:28:20 2010 Outbound Traffic Accepted Traffic - Default policy ICMP type 8 code 0 192.168.50.1->98.137.149.56 on clink1

Sep 20 13:28:20 2010 Outbound Traffic Connection opened : ICMP 192.168.50.1 10885 <-->192.168.50.1 10887 [98.137.149.56] type 8, trk 3 clink1 Null-NAPT Outgoing UNSECURED

Sep 20 13:28:19 2010 Outbound Traffic Accepted Traffic - Default policy ICMP type 8 code 0 192.168.50.1->98.137.149.56 on clink1

Sep 20 13:28:19 2010 Outbound Traffic Connection opened : ICMP 192.168.50.1 10885 <-->192.168.50.1 10886 [98.137.149.56] type 8, trk 2 clink1 Null-NAPT Outgoing UNSECURED

Sep 20 13:28:18 2010 Outbound Traffic Accepted Traffic - Default policy ICMP type 8 code 0 192.168.50.1->98.137.149.56 on clink1

Sep 20 13:28:18 2010 Outbound Traffic Connection opened : ICMP 192.168.50.1 10885 <-->192.168.50.1 10885 [98.137.149.56] type 8, trk 1 clink1 Null-NAPT Outgoing UNSECURED

0 Likes
Re: Advanced In Home Routing Issue
lasagna
Community Leader
Community Leader

The Null-NAPT statement would seem to imply no NAT being applied if I'm interpreting that correctly.     On a whim, what happens if you change the security level on the router to Medium instead of low?

Another thought, do you have a spare NAT router (like a Linksys)?   Insert this between the ActionTec and the home network (essentially placing the 192.168.1.x network of the ActionTec outside of your home network and put all the devices internally behind the Linksys (setting up the 192.168.50.x route there).   Use the Linksys in NAT mode which will hide everything from the ActionTec behind a single address (place this since address in the ActionTec DMZ so you don't have to do port forwarding in two locations).   This will be a double-NAT scenario, but would remove the ActionTec from the picture as the source of your issue.

Re: Advanced In Home Routing Issue
mtntrailseeker

Logs with firewall set to medium below.

While double natting works this isn't what's been running successfully from a HW solution, which baffles the heck out of me.

I don't find any evidence of a recent VZ firmware upgrade.  The CLI shows an upgrade back in late January.  I imagine that this FW has been running for a long time unless my "restore to defaults" the other day forced it active.

flash> layout
Flash layout:

Section 00 Type FACTORY    Range 0x00060000-0x00080000 MaxSize 0x0001FF6C
        Size 0x000002E6 Name 'Downloaded at: Fri Dec 14 19:00:21 2007'
        Checksum 0x0000B552 Counter 0x000055E3 Start Offset 0x00000000

Section 01 Type CONF       Range 0x00080000-0x000A0000 MaxSize 0x0001FF6C
        Size 0x00006BAF Name 'rg_conf'
        Checksum 0x00352D8F Counter 0x00007DE2 Start Offset 0x00000000

Section 02 Type CONF       Range 0x000A0000-0x000C0000 MaxSize 0x0001FF6C
        Size 0x00006969 Name 'rg_conf'
        Checksum 0x00346F01 Counter 0x00007CD9 Start Offset 0x00000000

Section 03 Type IMAGE      Range 0x000C0000-0x004C0000 MaxSize 0x003FFF6C
        Size 0x003A89E8 Name 'Downloaded at: Fri Dec 14 19:02:51 2007'
        Checksum 0x1D263783 Counter 0x00005565 Start Offset 0x00000000

Section 04 Type IMAGE      Range 0x004C0000-0x00CC0000 MaxSize 0x007FFF6C
        Size 0x004E0AF8 Name 'MC524WR Version 4.7.5.3.32.20.10.7 Downloaded at: Thu Jan 28 00:29:20 2010'
        Checksum 0x26DCE7B1 Counter 0x000057C3 Start Offset 0x00000000

Section 05 Type LOG        Range 0x00CC0000-0x00D00000 MaxSize 0x0003FF6C
        Size 0x00005419 Name 'Persistent_log'
        Checksum 0x002A8754 Counter 0x00007DD5 Start Offset 0x00000000

Section 06 Type BOOTCONF   Range 0x00D00000-0x00D20000 MaxSize 0x0001FF6C
        Uninitialized.

Total 7 sections found.

Returned 0
flash>

Logs

Time Event Event-Type Details

Sep 21 13:13:18 2010 Outbound Traffic Connection closed : ICMP 192.168.50.1 1755 <-->192.168.50.1 1757 [72.30.2.43] type 8, trk 10 clink1 Null-NAPT Outgoing

Sep 21 13:13:17 2010 Outbound Traffic Connection closed : ICMP 192.168.50.1 1755 <-->192.168.50.1 1756 [72.30.2.43] type 8, trk 9 clink1 Null-NAPT Outgoing

Sep 21 13:13:16 2010 Outbound Traffic Connection closed : ICMP 192.168.50.1 1755 <-->192.168.50.1 1755 [72.30.2.43] type 8, trk 8 clink1 Null-NAPT Outgoing

Sep 21 13:13:16 2010 Outbound Traffic Accepted Traffic - Default policy UDP 192.168.1.30:1034->192.43.244.18:123 on clink1

Sep 21 13:13:16 2010 Outbound Traffic Connection opened : UDP 192.168.1.30:1034 <-->98.119.11.240:1034 [192.43.244.18:123] clink1 NAPT Outgoing UNSECURED
 
Sep 21 13:13:15 2010 Outbound Traffic Connection closed : ICMP 192.168.50.1 1755 <-->192.168.50.1 1761 [72.30.2.43] type 8, trk 7 clink1 Null-NAPT Outgoing

Sep 21 13:13:14 2010 Outbound Traffic Connection closed : ICMP 192.168.50.1 1755 <-->192.168.50.1 1760 [72.30.2.43] type 8, trk 6 clink1 Null-NAPT Outgoing

Sep 21 13:13:13 2010 Outbound Traffic Connection closed : UDP 192.168.1.30:1033 <-->98.119.11.240:1033 [192.43.244.18:123] clink1 NAPT Outgoing FW-FASTPATH FP-CAP
 
Sep 21 13:13:13 2010 Outbound Traffic Connection closed : ICMP 192.168.50.1 1755 <-->192.168.50.1 1759 [72.30.2.43] type 8, trk 5 clink1 Null-NAPT Outgoing
 
Sep 21 13:13:12 2010 Outbound Traffic Connection closed : ICMP 192.168.50.1 1755 <-->192.168.50.1 1758 [72.30.2.43] type 8, trk 4 clink1 Null-NAPT Outgoing
 
Sep 21 13:13:12 2010 Outbound Traffic Accepted Traffic - Default policy ICMP type 8 code 0 192.168.50.1->72.30.2.43 on clink1
 
Sep 21 13:13:12 2010 Outbound Traffic Connection opened : ICMP 192.168.50.1 1755 <-->192.168.50.1 1757 [72.30.2.43] type 8, trk 10 clink1 Null-NAPT Outgoing UNSECURED
 
Sep 21 13:13:11 2010 Outbound Traffic Connection closed : ICMP 192.168.50.1 1755 <-->192.168.50.1 1757 [72.30.2.43] type 8, trk 3 clink1 Null-NAPT Outgoing
 
Sep 21 13:13:11 2010 Outbound Traffic Accepted Traffic - Default policy ICMP type 8 code 0 192.168.50.1->72.30.2.43 on clink1
 
Sep 21 13:13:11 2010 Outbound Traffic Connection opened : ICMP 192.168.50.1 1755 <-->192.168.50.1 1756 [72.30.2.43] type 8, trk 9 clink1 Null-NAPT Outgoing UNSECURED
 
Sep 21 13:13:10 2010 Outbound Traffic Connection closed : ICMP 192.168.50.1 1755 <-->192.168.50.1 1756 [72.30.2.43] type 8, trk 2 clink1 Null-NAPT Outgoing
 
Sep 21 13:13:10 2010 Outbound Traffic Accepted Traffic - Default policy ICMP type 8 code 0 192.168.50.1->72.30.2.43 on clink1

Regards,

Tom

0 Likes
Re: Advanced In Home Routing Issue
lasagna
Community Leader
Community Leader

The suggestion to use another router in the mix was to see if indeed the NAT is the issue on the ActionTec.   Since we can't truly see the packets on the WAN side (unless you're ethernet provisioned and and insert a tap and sniffer), we just don't know what the packet looks like on the outside.   The second router would prove or disprove that theory.

I'm confused about the log however in that I'm not seeing the source address on the 192.168.50.x network.   All I am seeing is the router address unless you are pinging from the router's address and I'm not seeing the address of the router's 192.168.1.x network interface (the log should contain all three for a system behind the router -- source addr, router addr, and dest addr) as the path which was being followed.

One suggestion ... I believe the router configurations are just XML.   You could try saving the current configuration and comparing it to the saved configuration to see if you can spot what might be different.   Might give a lead on what configuration directive is not set properly.

Re: Advanced In Home Routing Issue
mtntrailseeker

So I am doing a source ping from the routing device specifying for it to use the 192.168.50.1 gateway interface that resides on it.

If I do a "non souce ping" to the outside world it uses the 192.168.1.15 egress interface I have on it and naturally goes through.

I've tried to open and save the configuration file a number of times.  When it does open it's just a bunch of numbers and letters, nothing close to human readable like the old backup I made months ago readable in notepad.  For a while I thought something was toast in the WI424, but then I tried a restore of the cryptic file and alas It restored successfully.  It's like VZ doesn't want you to view what's in the file anymore. 

0 Likes
Re: Advanced In Home Routing Issue
lasagna
Community Leader
Community Leader

Might just be a different version of firmware with the "E" series router that uses a different file format for the save.

One more thing to test ... Have you attached a system directly to the 192.168.1.x network and tried to ping something on the 192.168.50.x network (and I mean two systems, not the routers).   Route on the system on the 192.168.1.x network should be a single default pointed to the ActionTec (which should issue an ICMP redirect and push your packet over the 192.168.1.15 interface for deliver to the system on the network behind that).   That will at least force a full packet travel path that doesn't utilize one of the devices involved in the actual routing as an endpoint.   If a ping works in both directions -- then that pretty much says is a NAT rule issue on the ActionTec.

I poked around on the AT looking for anywhere one might be able to setup NAT rules but didn't find anything. 

0 Likes
Re: Advanced In Home Routing Issue
mtntrailseeker

Yes, an end to end ping from a 192.168.1.x host to a 192.168.50.x host works fine with the following route statement below on the AT router.

Wireless Broadband Router> net
net> route
Source             Destination        Gateway            Flags DSCP Metric Interface      
0.0.0.0/0          192.168.50.0/24    192.168.1.15       UG    0    0      br0            
0.0.0.0/0          192.168.1.0/24     *                  U     0    4      br0            
0.0.0.0/0          {edited for privacy}     *                  U     0    3      clink1         
0.0.0.0/0          0.0.0.0/0          {edited for privacy}       UG    0    3      clink1         

Returned 0
net>

0 Likes
Re: Advanced In Home Routing Issue
lasagna
Community Leader
Community Leader

OK ... then we know all is good on the routing side.   That truly leaves only the NAT rule as the culprit I believe.  I did find a reference to NAPT configurations on the "external" broadband side of the configuration under the "Advanced" routing setting.  Makes no sense why you would need to put an entry here since the route obviously has to be defined on the "internal" side of the router.    However, for giggles, maybe you could try adding an inbound pointed route on the external side and select NAPT as the routing mode to see if somehow that triggers the AT to do the translation?  I'm going to have to see if I can replicate the setup and see if it exhibits the same problem with my "D" version AT.

0 Likes