Community discussions

MikroTik App
 
onlineuser
Member Candidate
Member Candidate
Topic Author
Posts: 225
Joined: Thu Aug 06, 2015 12:10 pm

routing problem

Wed Jan 04, 2017 10:13 pm

Hello,

the VPN tunnel from 33.3 to the external VPN server works - the 10.1.0.0 is from both sites of the tunnel reachable.

Which routes and NAT rules must I set on R1 and R2 that 10.1.0.6/10.1.0.1 are reachable from the 34.0 network through the 33.1 and 33.30?

Thanks, very much.
You do not have the required permissions to view the files attached to this post.
 
Revelation
Member
Member
Posts: 338
Joined: Fri Dec 25, 2015 5:59 am

Re: routing problem

Wed Jan 04, 2017 10:43 pm

Couple of things...

Is R1 acting as a NAT for the x.x.34.0/24 network; or is it just a router that routes the traffic?

How is routing between R1 and R2 handled currently? Can devices in x.x.33.0/24 "talk" directly with devices in x.x.34.0/24 without the use of a NAT?

In my opinion, the easiest thing would be to setup OSPF on R1 and R2 and have R2 advertise the network/IPs of the tunnel and beyond to R1. That is without knowing further details in how your network is setup. You can also use static routes.
 
onlineuser
Member Candidate
Member Candidate
Topic Author
Posts: 225
Joined: Thu Aug 06, 2015 12:10 pm

Re: routing problem

Thu Jan 05, 2017 8:44 am

Yes, 33.0 and 34.0 are NAT routed to the gateway (33.1) but 33.0 also routed directly to 34.0 without NAT (34.0 can directly communicate with 33.0).

Or can I solve it with port forwarding, that 33.1:1080 will be routed to 33.3:1080 and this will be routed through the tunnel to 10.1.0.1:1080?
I would need the tunnel only for socks proxy uplink.
 
Revelation
Member
Member
Posts: 338
Joined: Fri Dec 25, 2015 5:59 am

Re: routing problem

Thu Jan 05, 2017 3:16 pm

Yes, 33.0 and 34.0 are NAT routed to the gateway (33.1) but 33.0 also routed directly to 34.0 without NAT (34.0 can directly communicate with 33.0).
Say what?

So the gateway on R1 is the NAT for both networks? Where is your ISP connection?

If x.x.33.0/24 and x.x.34.0/24 can "talk" directly with each other without using a NAT, simply configure routing - whether it be static or dynamic.
Or can I solve it with port forwarding, that 33.1:1080 will be routed to 33.3:1080 and this will be routed through the tunnel to 10.1.0.1:1080?
I would need the tunnel only for socks proxy uplink.
You're trying to make this way more complicated than it needs to be. Also, without knowing how your network is configured, you could make things worse.
 
onlineuser
Member Candidate
Member Candidate
Topic Author
Posts: 225
Joined: Thu Aug 06, 2015 12:10 pm

Re: routing problem

Thu Jan 05, 2017 3:18 pm

ISP is on 11.0 on another port of R1.
Ok, I will try it with static routes.

UPDATE_1: On R1 I set following route: 10.1.0.0/29 via 192.168.33.3 (now from 34.0 10.1.0.6 is reachable).
But from 34.0 I cannot ping 10.1.0.1 (only 10.1.0.6 is reachable).

UPDATE_2: Ok, now it runs, I forgot the two forwarding rules on R2. ;-)

Thanks. :-)
 
onlineuser
Member Candidate
Member Candidate
Topic Author
Posts: 225
Joined: Thu Aug 06, 2015 12:10 pm

Re: routing problem

Sat Jan 07, 2017 5:52 pm

Everything works fine but I get a lot of TCP Resets on the 33.3 router. The tunnel and bandwidth are stable. On the OpenVPN server there are no suspicious entries.
15:05:04 firewall,info LAST DROP - INPUT input: in:OpenVPN out:(none), proto TCP (RST), 10.1.0.1:8080->10.1.0.6:61832, len 40
15:05:06 firewall,info LAST DROP - INPUT input: in:OpenVPN out:(none), proto TCP (RST), 10.1.0.1:8080->10.1.0.6:61855, len 40
15:05:06 firewall,info LAST DROP - INPUT input: in:OpenVPN out:(none), proto TCP (RST), 10.1.0.1:8080->10.1.0.6:61855, len 40
15:08:28 firewall,info LAST DROP - INPUT input: in:OpenVPN out:(none), proto TCP (RST), 10.1.0.1:8080->10.1.0.6:61931, len 40
15:08:28 firewall,info LAST DROP - INPUT input: in:OpenVPN out:(none), proto TCP (RST), 10.1.0.1:8080->10.1.0.6:61931, len 40
15:08:29 firewall,info LAST DROP - INPUT input: in:OpenVPN out:(none), proto TCP (RST), 10.1.0.1:8080->10.1.0.6:61850, len 40
15:08:29 firewall,info LAST DROP - INPUT input: in:OpenVPN out:(none), proto TCP (RST), 10.1.0.1:8080->10.1.0.6:61850, len 40
16:11:52 firewall,info LAST DROP - INPUT input: in:OpenVPN out:(none), proto TCP (RST), 10.1.0.1:8080->10.1.0.6:55070, len 40
16:11:52 firewall,info LAST DROP - INPUT input: in:OpenVPN out:(none), proto TCP (RST), 10.1.0.1:8080->10.1.0.6:55070, len 40
Sometimes I also get some SYN,ACK entries.
16:54:34 firewall,info LAST DROP - INPUT input: in:OpenVPN out:(none), proto TCP (RST), 10.1.0.1:8080->10.1.0.6:60734, len 40
16:54:34 firewall,info LAST DROP - INPUT input: in:OpenVPN out:(none), proto TCP (RST), 10.1.0.1:8080->10.1.0.6:60734, len 40
16:54:34 firewall,info LAST DROP - INPUT input: in:OpenVPN out:(none), proto TCP (RST), 10.1.0.1:8080->10.1.0.6:60734, len 40
17:06:02 firewall,info LAST DROP - INPUT input: in:OpenVPN out:(none), proto TCP (SYN,ACK), 10.1.0.1:8080->10.1.0.6:63361, len 52
17:06:10 firewall,info LAST DROP - INPUT input: in:OpenVPN out:(none), proto TCP (SYN,ACK), 10.1.0.1:8080->10.1.0.6:63361, len 52
17:06:26 firewall,info LAST DROP - INPUT input: in:OpenVPN out:(none), proto TCP (SYN,ACK), 10.1.0.1:8080->10.1.0.6:63361, len 52
The server (10.1.0.1) sends TCP resets to the client (10.1.0.6).

What could be the cause of this behavior?

Could this come from packets they come too late?
Maybe some packets needed too long and new one were requested and they reached before?
Websites will be loaded fully and without problems.
 
onlineuser
Member Candidate
Member Candidate
Topic Author
Posts: 225
Joined: Thu Aug 06, 2015 12:10 pm

Re: routing problem

Mon Jan 09, 2017 10:41 pm

noone any idea? :-(
 
onlineuser
Member Candidate
Member Candidate
Topic Author
Posts: 225
Joined: Thu Aug 06, 2015 12:10 pm

Re: routing problem

Tue Jan 17, 2017 7:50 pm

*push*
 
tclafoe
just joined
Posts: 7
Joined: Thu Dec 29, 2016 1:36 pm

Re: routing problem

Thu Jan 19, 2017 6:31 pm

TCP-RST are typically sent when either no server process is running on that port (8080 in your case) or some access control (iptables/firewall) actively rejects the connections for some reasons.
It also happens when the TCP state machine runs into a timeout while expecting another packet from the requesting client that did not come. This is normal behaviour to signal the requesting party that the connection will be terminated compulsorily and it should free all related resources (buffers, sockets, etc.)
Hope this helps.

Who is online

Users browsing this forum: svmk and 37 guests