FOR TIPS, gUIDES & TUTORIALS

subscribe to our Youtube

GO TO YOUTUBE

14455 questions

17168 answers

28195 comments

0 members

We are migrating to our new platform at https://community.teltonika.lt. Moving forward, you can continue discussions on this new platform. This current platform will be temporarily maintained for reference purposes.
+1 vote
708 views 3 comments
by anonymous

Hi,

I got a RUT955 with FW RUT9XX_R_00.06.07.5. I have a port based VLAN configured, where port 1 is set to lan and ports 2 and 3 are set to lan_avligt.

Zone Forwarding is configured as follows:

I can ping the router address from lan and lan_avligt no matter with what VLAN I am connected with. However I cannot reach another device in the other VLAN. I also tried to set the destination zones to the other LAN, e.g. on Source zone lan_avligt is set Destionation zone lan and vise versa but I cannot establish a connection between the two VLANs. Shouldn't that be possible without any specific port forwarding rule?

The person in this thread has the exact opposite problem and I wish it would work that way for my application.

Any ideas appreciated.

Ian

1 Answer

+1 vote
by anonymous

Hi,

While in the "Zone Forwarding" section, click 'Edit' next to lan or lan_avligt. Then tick the opposite LAN/VLAN network to allow forwarding to it and save changes. Do it for both lan and lan_avligt.

Like this.

DM

Best answer
by

Hi DM,

I tried that as well. But still can't reach any device in the other VLAN. Zone forwarding looks like this now:

lan is set to 10.177.77.1, connected device 10.177.77.17

lan_avligt to 192.168.100.1, connected device 192.168.100. 101

From 192.168.100.101 on the lan_avligt I try to ping 10.177.77.17 with 'ping: sendto: Network is unreachable' as a result . From the RUT955 I can ping both devices in both networks.

By editing the two networks as you suggested, the following lines are added or changed in the iptables output, nothing more:

Chain zone_lan_avligt_dest_ACCEPT (2 references)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             /* !fw3 */

Chain zone_lan_avligt_forward (1 references)
target     prot opt source               destination         
forwarding_lan_avligt_rule  all  --  anywhere             anywhere             /* !fw3: user chain for forwarding */
zone_lan_dest_ACCEPT  all  --  anywhere             anywhere             /* !fw3: forwarding lan_avligt -> lan */
ACCEPT     all  --  anywhere             anywhere             ctstate DNAT /* !fw3: Accept port forwards */
zone_lan_avligt_src_ACCEPT  all  --  anywhere             anywhere             /* !fw3 */

and

Chain zone_lan_dest_ACCEPT (6 references)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             /* !fw3 */

Chain zone_lan_forward (1 references)
target     prot opt source               destination         
forwarding_lan_rule  all  --  anywhere             anywhere             /* !fw3: user chain for forwarding */
zone_lan_avligt_dest_ACCEPT  all  --  anywhere             anywhere             /* !fw3: forwarding lan -> lan_avligt */
ACCEPT     all  --  anywhere             anywhere             ctstate DNAT /* !fw3: Accept port forwards */
zone_lan_src_ACCEPT  all  --  anywhere             anywhere             /* !fw3 */

So looks fine to me. Or should there be another change in IP tables?

Ian

by anonymous

No, everything looks good to me. I tested this with my Android phone and Windows PC, pings are going through successfully. 

It could be that the connected devices from 192.168.100.xxx do not accept traffic originating from 10.177.77.xxx or vice versa (depending on the device and OS, firewalls may act differently). One way to check is to enable masquerading on the router (also in the "Zone Forwarding" section) - if it works, then it's probably the firewall.

Also, a packet capture on lan and lan_avligt could provide information on where the packets are stopping. You can use tcpdump for that via SSH/CLI, or enable tcpdump via WebUI, in the System → Administration  Troubleshoot page. For end devices you can use Wireshark for packet captures (or the same tcpdump if using Linux).

Also also, if one or both devices have more than one default gateway each, it could be another reason why they can't communicate (because they might be trying to communicate over a different, WiFi Access Point, etc.)

I'm also attaching this backup file from my tests. It works for me with this config. Feel free to upload and explore. FW is the same as yours so, it should upload successfully. If it doesn't, tell me your product code (can be checked in the Status  Device page) and I can prepare a proper backup. (Password: Admin123MD5: fb0f5453696b3ba511f0cc0679fab670)

DM

by anonymous
Hi DM,

it works fine with another device on the VLAN. So I guess the original device didn't accept the the traffic, masquerading dind't help so I assume something is wrong with the rout settings on that device, but thats not a Teltonika issue. I tried several identical devices but a similar configuration.

Thank you very much for your help!

Ian