I need to resolve this issue.
I have one MT with public IP (Office) and another MT with non-public IP (Home).
I have a service runnig in HOME network in Windows PC. Id like to access from internet to this service. What I tried. Ive made a pptp connection between HOME and OFFICE and add the both private networks to the route tables. So now I can see (ping) all pc from OFFICE in HOME lan.
This is route table from OFFICE GW
If Id try to make connection I can see packet in the both firewall counters (OFFICE and HOME), I can open telnet connection in 3454 port from OFFICE gw to 192.168.88.248 (Win machine in HOME), but I cant login to the service (failed to connect to device from client).
Where is the issue?
From what you’ve posted and what you haven’t, it sounds like two distinct issues.
First, to redirect (dst-nat) the initial request packet from the client somewhere in the internet to the tunnel towards HOME at OFFICE, and then use another redirection at HOME to the actual device, is just one part of the story. With these dst-nat rules in place, the request packet reaches the actual device at home allright.
But now think about the response. For the device, the HOME router is probably the default route’s gateway, so the response packet is sent to the HOME device no matter what is its destination address. But as the destination address of the response is the source one of the request, and that one is public, the HOME router will send the packet to it via its own default route, which is its own WAN, which is likely src-nated. So the response packet will reach the client with a source address of the HOME router’s WAN, which is different from the OFFICE router’s WAN to which the client has sent the request, so the client will ignore the response as it will come from an unknown source.
You have two possibilities how to fix this:
use src-nat (or masquerade) in OFFICE also for packets sent via the tunnel to HOME. This way, the HOME router will see the request as sent by OFFICE’s IP on the tunnel, so it will send the response from the actual device to the tunnel rather than up to the default route. On the OFFICE, the response will be un-src-nated at reception and un-dst-nated on transmission, so the OFFICE will forward it to the client with a correct source and destination address
if you want the actual device to know the address of the client for some reason, use policy routing with connection marking at the HOME router, to make sure that requests which came in via the tunnel will be responded via the tunnel, no matter what the destination address of the responses is.
Regarding the other issue - if I got you right, you can telnet from the OFFICE machine itself to the actual device but cannot login to it; are we still talking about telnet when mentioning login? Or do you use telnet just to check that the TCP connection establishes allright but the actual protocol used is a different one?
From what you’ve posted and what you haven’t, it sounds like two distinct issues.
First, to redirect (dst-nat) the initial request packet from the client somewhere in the internet to the tunnel towards HOME at OFFICE, and then use another redirection at HOME to the actual device, is just one part of the story. With these dst-nat rules in place, the request packet reaches the actual device at home allright.
But now think about the response. For the device, the HOME router is probably the default route’s gateway, so the response packet is sent to the HOME device no matter what is its destination address. But as the destination address of the response is the source one of the request, and that one is public, the HOME router will send the packet to it via its own default route, which is its own WAN, which is likely src-nated. So the response packet will reach the client with a source address of the HOME router’s WAN, which is different from the OFFICE router’s WAN to which the client has sent the request, so the client will ignore the response as it will come from an unknown source.
I had he same idea, but there is strange I can delete 2nd dst-nat (In HOME MT) and nothing changed. I can ping win machine and I can telnet win machine in 3454. So it seems dst-nat in so important in this case.
This is without dst-nat in HOME.
admin@MikroTik] > system telnet 192.168.88.248 3454
Trying 192.168.88.248…
Connected to 192.168.88.248.
Escape character is ‘^]’.
But I cant do it from my pc (internet) if Im connected to the OFFICE via VPN (connection time out), I can`t ping 192.168.88.248.
You have two possibilities how to fix this:
use src-nat (or masquerade) in OFFICE also for packets sent via the tunnel to HOME. This way, the HOME router will see the request as sent by OFFICE’s IP on the tunnel, so it will send the response from the actual device to the tunnel rather than up to the default route. On the OFFICE, the response will be un-src-nated at reception and un-dst-nated on transmission, so the OFFICE will forward it to the client with a correct source and destination address
if you want the actual device to know the address of the client for some reason, use policy routing with connection marking at the HOME router, to make sure that requests which came in via the tunnel will be responded via the tunnel, no matter what the destination address of the responses is.
I had the same idea again;o). But I dont want mangle all packets in prerouting from 192.168.88.248 and sent them via tunnel, so now Ill want to try src-nat option.
I have to be very carefull because I do it all remotly (Teamviewer in 192.168.88.248 and VPN in OFFICE), so If I make some mistake I can lost connection and I`m out of game;o).
Add masqurade helped with ping…I can ping 192.168.88.248 via VPN now, but I still can`t make telnet connection from pc.
Very strange is ping (tracert) working corectly.
I added route 192.168.100.0/24 in HOME (this is VPN subnet) and now I can tracerouting win machine from my pc via VPN and win machine can traceroute me.
If icmp working correctl why tcp not?
I’d have to see the configs of both OFFICE and HOME machines to be able to suggest something. The difference between ping handling and TCP handling may be that you have placed the permissive rule for the TCP to a wrong place in the firewall.
Also, the “PC” is what? A client trying to access the camera server via OFFICE’s public IP, on which you also run the VPN client to OFFICE?
Regarding breaking something - Safe Mode is your friend. Ctrl-X in command line, or a button in Winbox/WebFig. If you lock yourself out, the machine notices that and reverts the configuration to the state before you’ve entered the Safe Mode. Just don’t do too many steps at a time, it can remember up to something like 100 changes if I remember well.
Safe mode is not working correctly every time;o).
Now I tried make masquerade in the both side of tunnels and enable again dst-nat in HOME and it seems packet is lost from my pc because counter in fw is 0.
For better understanding.
my pc------VPN(Office)---------GW(Office)-------VPN-----Gw(HOME)----lan HOME 192.168.88.248 is camera server.
Office
[admin@MikroTik] > ip firewall nat print
Flags: X - disabled, I - invalid, D - dynamic
0 ;;; defconf: masquerade
chain=srcnat action=masquerade out-interface-list=WAN
ipsec-policy=out,none
[admin@MikroTik] > ip route print
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 ADS 0.0.0.0/0 192.168.0.1 1
1 A S 172.16.0.0/24 Firma 1
2 ADC 192.168.0.0/24 192.168.0.34 ether1 0
3 ADC 192.168.88.0/24 192.168.88.1 bridge 0
4 A S 192.168.100.0/24 Firma 1
5 ADC 192.168.100.18/32 192.168.100.100 Firma 0
As you can see I have doble masquerade in the tunnel and dst-na enable in the HOME…I suppose it should working but not.
Of course now I try 192.168.100.100 as a destination IP from my pc (this is ip HOME MT in VPN).
Its working...but I cant be at VPN. I tried connect via mobiles data and it working with double masquerade. But I``m not still understand why it doesnt working via VPN.
Edit: Hm its working via vpn too...Im crazy about it.
Resolved.
The question is if is the best scenario for this case.