Routing quesion. Please don't laugh

[meyery2k]

I have done these about a hundred times but I have just this one that is causing me grief.  Two subnets  VLAN 1 10.9.0.0/24 and VLAN 2 172.16.0.0/16 for VoIP.  The customer has a firewall on VLAN 1 10.9.0.254 and I have assigned VLAN 1 10.9.0.253.  VLAN 2 is 172.16.2.1

They have recently set up an office with VPN and I need to have traffic go between VLAN 1 and VLAN 2 so the VOIP will work.  I built a static route for 0.0.0.0 0.0.0.0 next hop 10.9.0.253 and I have been assure a route for 172.16.0.0/16 next hop 10.9.0.254 has been built in the firewall.

Apparently devices on VLAN 2 can be pinged from devices on VLAN 1.  I cannot ping devices on VLAN 1 from devices on VLAN 2.  When I do a trace route on a PC that last successful hop is 172.16.2.1

Firewall on the Adtran is not enabled.  I know it is a routing issue but we are kinda pointing at each other saying it is not me.  Anything to break the logjam would be appreciated.

Config is below for review.  Please don't laugh I know this is extremely basic and I have done this many time before.  I don't have access to the customer Sonicwall where I suspect the issue to be.  I just need to prove it.

I CAN ping the Adtran Vlan 1 host .253 from a host on VLAN 2.  I CANNOT ping .254 which leads me to believe the Sonicwall is missing a route or rules to allow traffic between the subnets.  I just can't convince the IT guy.  This could be so simple...

Thanks in advance for your help. ~ Mike

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2014.07.30 12:10:28 =~=~=~=~=~=~=~=~=~=~=~=
sh run
Building configuration...
!
!
hostname "WaileaGCAdmin"
enable password ************
!
!
ip subnet-zero
ip classless
ip name-server 24.25.227.64 4.2.2.1
ip routing
!
event-history on
no logging forwarding
no logging email
logging email priority-level info
!
username "admin" password "********************"
!
!
no ip firewall alg h323
no ip firewall alg sip
!
!
!
!
aaa authentication port-auth default local
!
!
!
qos queue-type wrr 25 25 25 expedite
!

qos dscp-cos 0 8 16 24 32 40 48 56 to 0 1 2 3 4 5 6 7

!
!
!
vlan 1
  name "Default"
vlan 2
  name "VoIP"
!
interface eth 0/1
  power inline never
  no shutdown
!
interface eth 0/2
  power inline never
  no shutdown
!
interface eth 0/3
  no shutdown
!
interface eth 0/4
  no shutdown
!
interface eth 0/5
  no shutdown
!
interface eth 0/6
  no shutdown
!
interface eth 0/7
  no shutdown
!
interface eth 0/8
  no shutdown
!
interface eth 0/9
  no shutdown
!
interface eth 0/10
  no shutdown
!
interface eth 0/11
  no shutdown
!
interface eth 0/12
  no shutdown
!
interface eth 0/13
  no shutdown
  switchport access vlan 2
  qos trust cos
!
interface eth 0/14
  no shutdown
  switchport access vlan 2
  qos trust cos
!
interface eth 0/15
  no shutdown
  switchport access vlan 2
  qos trust cos
!
interface eth 0/16
  no shutdown
  switchport access vlan 2
  qos trust cos
!
interface eth 0/17
  no shutdown
  switchport access vlan 2
  qos trust cos
!
interface eth 0/18
  no shutdown
  switchport access vlan 2
  qos trust cos
!
interface eth 0/19
  no shutdown
  switchport access vlan 2
  qos trust cos
!
interface eth 0/20
  no shutdown
  switchport access vlan 2
  qos trust cos
!
interface eth 0/21
  no shutdown
  switchport access vlan 2
  qos trust cos
!
interface eth 0/22
  no shutdown
  switchport access vlan 2
  qos trust cos
!
interface eth 0/23
  no shutdown
  switchport access vlan 2
  qos trust cos
!
interface eth 0/24
  no shutdown
  switchport access vlan 2
  qos trust cos
!
!
interface gigabit-eth 0/1
  description BlueCourse
  speed 1000
  power inline never
  no shutdown
  switchport access vlan 2
  qos trust cos
!
interface gigabit-eth 0/2
  description GoldCourse
  speed 1000
  power inline never
  no shutdown
  switchport access vlan 2
  qos trust cos
!
!
interface vlan 1
  ip address  10.9.0.253  255.255.255.0
  no shutdown
interface vlan 2
  description VoIP
  ip address  172.16.2.1  255.255.0.0
  no shutdown
!
!
!
!
!
!
ip route 0.0.0.0 0.0.0.0 10.9.0.254
!
no ip tftp server
ip http server
no ip http secure-server
no ip snmp agent
no ip ftp agent
!
!
!
!
!
!
!
!
line con 0
  login
  password **********
!
line telnet 0 4
  login
  password ***************
!
!
!
!
!
end
WaileaGCAdmin#exit

[Anonymous]

Hi meyery2k:

I'm not sure about the VPN component in this scenario.  Assuming it's terminated by the SonicWALL, it may be that VPN selectors must be changed to allow remote hosts to communicate with the 172.16.0.0/16 network; perhaps only 10.9.0.0/24 can be accessed by the far end.  But that doesn't seem to pertain to the more basic goal of allowing hosts on VLANs 1 and 2 to communicate (local site only).

If hosts in VLAN 1 can ping hosts in VLAN 2, then it means ICMP reply packets from VLAN 2 hosts are able to route back to the hosts in VLAN 1.  I think this demonstrates that sufficient routes exist.  However, I'm not sure about the particular tests/hosts you tried.  Can you confirm the default gateway assignments for the hosts involved (both VLANs)?  The ADTRAN switch would be a valid option in both subnets, but sometimes there are other considerations, such as security or traffic optimization.  For the purposes of testing, you might want to just pick a host in each subnet and set the VLAN 1 host's default gateway to 10.9.0.254; VLAN 2 host's default gateway 172.16.2.1.  Is it possible that another router is being used as a default gateway for some hosts and it just needs a static route added?

Are you confident that no other host uses IP address 10.9.0.254?  If the SonicWALL is .253 then one might assume it is because .254 was allocated and they were working down from the end of the subnet.  Just a thought...

Chris

[meyery2k]

Chris,

Thank you for the response.

What I know is below…

[Anonymous]

Are you referring to your original post?  Sorry if I'm missing new information...

[meyery2k]

Sorry –

I goofed on the original post and have corrected it. The SonicWall is .254 and Adtran VLAN 1 is .253 (long couple days sorry)

I don’t really have access to customer devices. If I have to I can visit site with a laptop and prove this but we are trying to avoid this. The IT person is working with me so far but I am not sure how to demonstrate it is not me without going there.

All hosts on VLAN 2 use 172.16.2.1 as a GW. I CAN ping 10.9.0.253 from a host on VLAN 2. This tells me the Adtran routes. I cannot ping .254, the sonicwall, which I believe does not have a route or maybe even rules to allow traffic.

To me I think my job is done but the IT person believes otherwise. Again, he is cool so I am willing to help but I am at the point where I believe that I have done all I can do.

[Anonymous · Accepted solution]

Ah, got it.  Seems like the ADTRAN is correctly configured.  If you can talk the IT person into changing the default gateway for one host, briefly, it may prove that your configuration is correct.  For example, the IT person sets up a laptop with IP address 10.9.0.252 (or whatever is unused), subnet mask 255.255.255.0, default gateway 10.9.0.253 (ADTRAN, not SonicWALL).  This should not break anything for the laptop because the ADTRAN's default route is the SonicWALL.

See if the laptop can ping a host in VLAN 2.  See if that host can ping the laptop.  If these tests pass, then the SonicWALL may need its static route to 172.16.0.0/16 via 10.9.0.253 corrected.  Or it may need security-related adjustments to allow the traffic in question.  Either way, it would point toward the SonicWALL as the culprit.  If the tests fail, bypassing the SonicWALL completely, then we should focus on the ADTRAN or maybe look into other factors.  Make sure the test laptop is connected to the ADTRAN while testing, to a switchport in VLAN 1.  Other switches could have security features getting in the way.

Chris

[meyery2k]

Chris,

Thank you for the support! I knew I wasn’t crazy. I am an old school telecom tech that learned IT out of necessity. I don’t pretend to be any kind of expert but I can certainly do a static route with no firewall involvement.

Excellent suggestion to change the GW. Should have no effect because the default route of the Adtran is the Sonicwall.

Mike

[Anonymous]

Me too, Mike. But isn't this stuff fun?

Be sure to let us know how it turns out, will you?

[Anonymous]

Mike,

     Based on the config you supplied I am not sure why you are doing any routing on the Adtran at all, I would turn off all the routing so that the only routing occurring is happening on the Sonicwall.  In this setup all you need is Layer 2 traffic, the only IP that should be on the Adtran switch at all is a management IP address for VLAN 1, VLAN 2 should have no IP address.  Also you either need at least one port configured as a Trunk port connecting to the Sonicwall or you need to have 2 ports connect to the Sonicall one on VLAN 1 and the other on VLAN 2 depending on how the Sonicawall is configured. The Sonicwall would then be 172.16.2.1 on VLAN 2 interface, and 10.9.0.254 on it's VLAN 1 Interface.  All devices talk to the SonicWall directly and the Sonicwall handles all the routing.  Since the two networks are directly connected you should have proper communication internally.

John Wable

[Anonymous]

You might be onto something, John.  That should function too, and may ease security configuration in the SonicWALL.  The 1200 series are a fine Layer 3 Lite switch, though.  If there will be significant traffic between VLAN 1 and VLAN 2, then it may be best to route (switch at Layer 3) using the 1200 between VLANs.  This is done at wire speed.  The 1200 would need to be used as the default gateway for hosts in both subnets for best results.

If there isn't much traffic going between VLANs, then it probably doesn't matter which approach you take, Mike, and giving the SonicWALL an IP interface in both VLANs could prove simpler for the IT person there.

[meyery2k]

John,

Thank you.

Yes I see where that would work. Unfortunately there is no one that really knows how to configure things on the Sonicwall or they are unwilling to.

Some progress was finally made after the admin built a static route in the Sonicwall. Traffic is flowing between the 2 VLANs.

I can see where your suggestion would be much cleaner and would implement it if the admin on the Sonicwall could be done.

It started off where the VoIP was completely separated physically and logically from the other data at the customer’s request. This is no longer possible since a dedicated fiber to one of the sites has been broken and will not be repaired because they are moving.

So I put addresses on VLAN 2 on all switches so I could get into them for troubleshooting VoIP. There is a RAS server (I know, I know, this was setup 7 years ago) on VLAN 2 so I can remote access.

For my part I have had to do very little troubleshooting and not had to deal to much with the IT admin who, unfortunately, is not knowledgeable about VLAN and routing and the Sonicwall configuration.

I have to play the bad cards I have been dealt here.

Thank you

Mike

[Anonymous]

Great to hear you have hosts talking now between VLANs, Mike.  Let us know if you encounter any more issues there.

Chris

[meyery2k]

Thanks! He still has to figure out how to get traffic from the VPN talking to 172.16 but I figure that is all sonicwall rules there and nothing to do with me.

Mike

[Anonymous]

Mike,

    Yes I hate it when you have to do things more complicated then they need to be.  Glad the issue has been worked out.

John

[Anonymous]

Mike,

    There will probably be an issue with this side of it hopefully not. But If it does become an issue you need to talk to the person about getting the VLAN setup on the Sonicwall and taking the routing off the Adtran so there is not a double route occurring on the traffic. If he just added a static route on the Sonicwall telling 10.9.0.X to go to 10.9.0.253 to access 172.16.2.X the VPN most likely will not work because it will be a whole new subnet for the VPN traffic.  If all routing is handled at the Sonicwall then all three subnets become directly connected networks and it makes the setup and configuration for you and him a whole lot cleaner and easier to manage.  But as you say it is on him to figure out.

John

[meyery2k]

John,

Thank you for the good advice. I can pass it on and see where it sticks. I dislike getting to the point where I can no longer assist someone but the fact is that, based on what I have for resources, I have Adtran configured correctly and it is not my responsibility to maintain the SonicWall.

I do appreciate the pointer and I will pass it on. Maybe the admin will finally break down and get some help from Sonicwall or someone knowledgeable on it.

Mike

[Anonymous]

Hey John, does SonicWALL handle VPN differently than AOS, in principle?  If it's a similar approach, or better yet a standards-based IPSec implementation, then VPN selectors need to be added.  172.16.0.0/16 must be allowed as a source network for the VPN tunnel and 172.16.0.0/16 must be added as a remote/destination network in the far end firewall.  In this sense, it shouldn't matter whether the SonicWALL has a 172.16.0.0/16 IP interface or merely routes there via the 1200 switch.  But it may be completely different and this is where my ignorance of SonicWALL is exposed. 

If you get a definitive answer from the SonicWALL person, Mike, consider sharing the knowledge here.  It seems like a scenario any of us could encounter as SonicWALLs are popular devices.

Chris

[Anonymous]

meyery2k:

I went ahead and flagged the "Correct Answer" on this post to make it more visible and help other members of the community find solutions more easily. If you don't feel like the answer I marked was correct, feel free to come back to this post and unmark it, and select another in its place, with the applicable buttons. 

Thanks,

Levi