WAN IP Address

22 posts / 0 new

Thu, 01/05/2017 - 01:19

Ai6bx

WAN IP Address

I have a Toughswitch 5 configured for three DtD nodes, 1 lan, and one WAN. Port 1 has a nanostation M2 XM as a WAN Gateway, Port 2 is LAN for port 1 with a Raspberry PI running Asterisk attached. Port 3 has a Nanobridge M5 attached, Port 4 is an AR with two webservers, VOiP phone, AP, and a couple Raspberry Pis attached. This node is configured for 13 DHCP addresses. Port 5 is my WAN port.

All works as it should however the Nanobridge on port three is somehow obtaining a WAN address of 192.168.2.20 which is from my home router. All port forwarding from the home router to the mesh i assigned to 192.168.2.1x so I am not certain how this is happening.. The Nanobridge is running 3.1.6. I have rebooted to see if this would resolve and also just let things sit for about 48 hours hoping it might correct once DNS records had a chance to cycle and confirm. No changes. Any ideas or suggestions?

Keith - AI6BX

Thu, 01/05/2017 - 01:25

K5DLQ

Port 3 must be part of VLAN1

Port 3 must be part of VLAN1 (WAN)

Thu, 01/05/2017 - 01:58

Ai6bx

Copied Program from site

I am using the same configuration from the AREDN site and have check settings multiple times.

Trunk Ports Enabled Management VLAN ID Comment Port 1 Port 2 Port 3 Port 4 Port 5

X		1	Management	T	T	T	T	U
X		2	DTD	T	E	T	T	E
X	X	11	VLAN11	U	U	E	E	E

Is there an error here?

Thu, 01/05/2017 - 02:13

Ai6bx

I am guesing

I am guessing port 3 under VLAN1 should be an E rather than T? If this is correct, the images on the website need to be corrected.

Thu, 01/05/2017 - 02:19

Ai6bx

That did it

Thanks for pointing me in the right direction. Should I contact someone about the need to correct the image on the website? It should be as follows:

X		1	Management	T	T	E	T	U
X		2	DTD	T	E	T	T	E
X	X	11	VLAN11	U	U	E	E	E

Thu, 01/05/2017 - 03:02

(Reply to #5) #6

KG6JEI

Initial image (all tagged)

Initial image (all tagged) looks right to me.

Its ok for each of your mesh nodes to have a WAN ip, it allows each one out to the internet to get updates (for when there is no meshgw enabled on any node)

By disabling the tagging on vlan 1 you have made it so the device is able to speak DTDLink but not able to directly connect to Internet to get updates.

Thu, 01/05/2017 - 09:45

Ai6bx

I thought about this

I thought about the some more after making the change and it did seem odd as if this were the root problem, the other nodes on 1 and 4 should be doing the same thing. What was corrected, and what I failed to mention in the first post, was that I could now get to the node from external port forwards. I have port forwards set up for each of my key nodes so I can access remotely from the internet if needed for management. This node, on port 3, failed to allow the protocol to work and sewing the different WAN IP address seemed to be the odd denominator. Changing port 3 to exclude resolved this but it does not seem it is truly the correct fix as all other nodes work with the same settings.

Fri, 01/06/2017 - 00:45

Ai6bx

Further testing

Based on KG6JEI's comment, I changed back to all tagged and the WAN IP re-emerged and my port forward again failed. I can access the Internet but cannot access the node remotely as I do with others and as possible when the tag is removed. The curious thing is that other attached nodes set for DTD with the management ports tag do not show WAN IP addresses and are accessible via port forwards. I am at a bit of a loss. Open to all speculation and thoughts on what is happening.

Keith

Fri, 01/06/2017 - 01:04

(Reply to #8) #9

KG6JEI

Please attach support data

Please attach support data files for each node so your settings on each node can be reviewed to understand your deployment.

Tue, 01/10/2017 - 12:02

(Reply to #9) #10

KG6JEI

The support files attached

The support files attached show that the NSM2 has a WAN IP address (as I would expect) at the time of the data file creation it was 192.168.2.18). I also see this is the node you have performing all your port redirections internally.

Your saying the web interface does not show this information? (screenshot may be helpful)

I see the NanoBridge has an IP of 192.168.2.20, there could possibly be an address conflict on your home network, while I would expect DHCP to self resolve this its possible something is prohibiting it.

Tue, 01/10/2017 - 12:08

(Reply to #10) #11

K5DLQ

(for WAN) The NSM2 is on a

(for WAN) The NSM2 is on a 192.168.2.x network and the NanoBridge is on a 192.168.1.x network??? That doesn't look right.

Tue, 01/10/2017 - 12:24

(Reply to #11) #12

KG6JEI

Sorry, typo on my side. Post

Sorry, typo on my side. Post corrected. They are both on the 192.168.2.x network.

Tue, 01/10/2017 - 15:12

(Reply to #12) #13

Ai6bx

They are both on the 192.168.2.x network

They are both on the 192.168.2.x network. The NSM2 has a statically assigned address of .18 from the network and somehow the NanoBridge is picking up the .20 through DHCP unless the port is excluded on the managemnt VLAN.

Tue, 01/10/2017 - 15:09

(Reply to #13) #14

Ai6bx

You are correct

Yes, the NSM2 has a WAN IP of 192.168.2.18 which is correct as it is statically assigned in my home router to support the WAN Gateway and port forwards for my IRLP and Echolink nodes at my repeater site as well as the ability to get firmware updates to remote nodes and administration of remote nodes from outside the mesh if needed via port forwards. This IP does show on the web interface so all is working well on this node.

The NanoBridge for some reason is getting the 192.168.2.20 as a WAN IP and showing it on the web interface as well. I am not sure how it is getting this address or why however with this in place, my port forward from the outside world is not working. as soon as I exclude the port from the management line on my TS this IP goes away and all works as it should. I will have to get into my home router more tonight to see how this could possibly be getting assigned as is it should not since this node does not have direct connection to the home router and the third node attached to the TS is not acquiring a WAN IP.

Tue, 01/10/2017 - 15:52

(Reply to #14) #15

KG6JEI

The NanoBridge is suppose to

The NanoBridge is suppose to pickup an IP on its WAN interface from your home network when the VLAN is tagged. When you put it in tagged mode on the switch you are telling the switch "Route my home network to the WAN port of the NanoBridge so it can get an IP address on my home network".

This is 100% as designed and correct.

The only other device you have shown is an AirRouter and it has its own WAN port. WAN is not looked for on the LAN ports on an AirRouter so of course it can not obtain an IP from your home network.

So all that is normal.

I now see you have manually edited the firewall rules to add port forwards to remote mesh nodes, this is unsupported and is at your own risk.

I'm going to back out of this discussion at this time as it appears this issue is caused by an unsupported modification to the mesh node configuration.

Wed, 01/11/2017 - 21:28

(Reply to #15) #16

Ai6bx

Thank you

Thank you, this definitely helps my understanding of what is going on.

keith

Fri, 01/06/2017 - 13:34

#17

Ai6bx

Support Files

I am attaching support files for the three nodes attached to the switch as well as the file from the switch itself. Note that I have sent two files for the node in question, one with port three tagged and one with it excluded.

Keith

Sat, 01/07/2017 - 01:34

#18

Ai6bx

Did the support files come through

Did the support files come through? I compressed multiple files into a single and am not sure if they sent properly.

Thx!

Sat, 01/07/2017 - 01:42

(Reply to #18) #19

K5DLQ

no. at the bottom of the

no. at the bottom of the reply page, you should add the "Support File Attachment" to your post

Sat, 01/07/2017 - 02:27

#20

Ai6bx

Support Files

Support Files, for a second time.

Support File Attachments:

Support files requested

Mon, 01/09/2017 - 23:58

#21

Ai6bx

Support files

Did the requested support files make it through this last time?

Tue, 01/10/2017 - 09:26

(Reply to #21) #22

WU2S

Yes

Yes, they were attached to your last message

Amateur Radio Emergency Data Network

Menu SF

You are here

WAN IP Address

Amateur Radio Emergency Data Network

Search form

Menu SF

You are here

WAN IP Address