I know this one is not related to the topic subject but this is my another router configurations, if you got time take look it and tell me if there is anything like a problem or something with it (firewall) that can be fix.
Other router configurations (with static IP).txt (6.65 KB)
I know I thought since I had problem with that bringing that up might help with the actual topic of the subject.
Okay I tried it but it shows nothing and then I thought okay what if I try with L2TP again and it shows this things so maybe this is telling us that port forwarding is correct and for some reasons IKEv2 is not initiating from client. is there anything I should’ve enabled in order for it to initiate? are Src Address & Dst Address are correctly set?
Also with the client (home) I can connect to another L2TP server without any problem (even before adding those two firewall rules) (don’t have the access to the server) so maybe both UDP port 500 and UDP port 4500 are forwarding correctly on the client side and we got a problem with server side or either the settings (Src Address & Dst Address) are wrong
Client side:
Server side:
Now wait - the server has a public IP on itself after all? If so, no port-forwarding is necessary at its side. Sorry, too many similar topics.
L2TP client should send packets to port 500 on the server’s address; IKEv2 initiator should send packets to port 4500. Both should be shown by the sniffer.
You don’t need to set any port forwarding on the client side. Show me /ip firewall filter export from the server, please.
yeah it's 5.xxx.xxx.xxx but on Route List you can see it's also connected to a xx.xx.xx.xx which is a public IP as well
here you go man:
sep/27/2021 by RouterOS 6.48.4
software id =
/ip firewall filter
add action=accept chain=input dst-port=500,4500 in-interface-list=all protocol=
udp
add action=accept chain=input dst-port=1701 in-interface-list=all ipsec-policy=
in,ipsec protocol=udp
add action=drop chain=forward port=25,110,465,587,2525,3535 protocol=tcp
add action=drop chain=forward port=25,110,465,587,2525,3535 protocol=udp
add action=accept chain=input dst-port=53 protocol=udp src-address-list=
Allow_VPN_DNS
add action=drop chain=input dst-port=53 protocol=udp
add action=accept chain=input dst-port=53 protocol=tcp src-address-list=
Allow_VPN_DNS
add action=drop chain=input dst-port=53 protocol=tcp
add action=accept chain=input limit=30,50 protocol=icmp
add action=drop chain=input protocol=icmp
OK, so I have swapped the roles of the routers when checking the configurations, and the one without a firewall is actually the server one, with the public IP directly on itself. Great. The right thing to do would be to disconnect it from the internet, netinstall it with the default configuration, restore the export there line by line but leaving out the firewall, except if the router is one of the higher models where no firewall is present in the default configuration. If that’s the case, you have to create the minimum set of firewall rules first, before connecting it to internet again. And never use any of the passwords used before the netinstall again. The filth from the net is incredibly fast in squatting in if it could collect the credentials using the vulnerability in older RouterOS versions.
Nevertheless, in such a case, if you enable the IKEv2 peer and the identity associated to it on the client, you should see packets to arrive to 5.x.x.x:4500 if you run /tool sniffer quick port=4500. If you don’t, something is rotten somewhere outside the server side router.
It may take some time between retries, so sniff for at least two minutes before declaring it a fail.
It’s on VMware
Okay so now after you said there is no firewall on the server the many logs with “TCP connection established from 178.128.66.56” with diffrent IP address make sense
Should I tell the guy for netinstall or just do it myself, I mean cause it’s on the vmware after resetting am I gonna be able to access it?
right now when I run /tool sniffer quick port=4500 on both side I got only sends on client but nothing on server side. I’m worried maybe I should use the other public IP (the one server itself connected to) or different LAN IPs.
I used 192.168.11.111 (client) which is the router, is it correct or I should use 192.168.11.0 or 192.168.0.254 (modem)?
If it’s on a VMware you can manage, just delete the VM and deploy it again from the template, but do not connect the internet-facing interface before you set up the basic firewall rules:
/interface list
add name=WAN
/interface list member
add list=WAN interface=ether1
/ip firewall filter
add chain=input connection-state=established,related action=accept
add chain=input connection-state=invalid action=drop
add chain=input protocol=icmp action=accept
add chain=input in-interface-list=WAN protocol=udp dst-port=500,4500 action=accept
add chain=input in-interface-list=WAN protocol=udp dst-port=1701 ipsec-policy=in,ipsec action=accept
add chain=input in-interface-list=WAN action=drop
No rules in chain forward as you seem not to use it as an actual router so far.
On the other hand, if the goal is to test sha512, why don’t you deploy two CHRs on it and let them establish an IPsec tunnel to each other? It will definitely be a better througphut test than via some LTE overseas…
No all I got is winbox access
If so, and since the whole exercise is only for evaluation of sha512, leave it as it is, just be ready that the CHR may start sending tons of spam somewhere. And revert back to investigation why packets to port 500 do make it through whilst packets to port 4500 don’t.
When you enable the peer & identity at the client and run the same /tool sniffer quick port=4500 on it, can you see the attempts there?
Yes
Okay… let’s do another thing then, set the port parameter on the /ip ipsec peer row at the client to 500, and sniff at both the server and the client with port=500 (still with IKEv2, not L2TP/IPsec). What’s the result?
I managed to screw the server firewall rules so it’s not accessible anymore. gonna give that guy a call to reset or fix it. then I will try this. Thanks for all the help man, I really appreciate it.