You can see this from the various messages posted above.ġ) wrong IP Sec shared secret and user credentialsĢ) correct IP Sec shared secret but incorrect User credentialsģ) some combination of wrong user name or password The script does not work when the "negotiation failure" message syntax formatted differently than above. I believe this is when the VPN server is hit by a client with little or no configuration so the proposal fails in total. Any ideas?Ĭode: Select all x.x.x.x phase 1 negotiation failed Next - I tried to blend the time element back into the script, but I must have the syntax wrong as I get no output. So that is of no use right? Although it contains an IP in the message.Īm I right in thinking that one message an attempt to gain access with all the incorrect information, shared secret and/or user credentials, and the shorter message is correct shared secret, but incorrect user credentials? Should we try to catch both? It would seem the exposure to people hitting the ports with no secret or user credentials is greater? Or is it that that the shared secret gets out someone may use it with random user names and passwords? Either way - if I understand the output - the first lines of output make parsing the IP much more difficult or impossible? So it pulls the "negotiation failed" part, but the source IP in one of those src_ip=phase 1. Where the first IP address is the server and the second is the user. Script=IPSEC_failed src_ip=phase1 msg=phase1 negotiation failed due to time up x.x.x.x(xxx)x.x.x.x(xxx) alksj qwlej lqw:13245j23 j lj I can certainly see it pulling the two different types of messages.įor clarity - the top messages looks something like: Pulls a little different output that looks like the following. :put "script=IPSEC_failed src_ip=$ip msg=$logMessage" not sure why it is not picking up the time of the message containing "negotiation failed" That is an uneducated guess.Įdit: if I make - 0m it will return a blank. I am guessing it is not pickup up the system time of that message, yet still trying to subtract 24h thus the hex. I am using my cell VPN to hit the correct address with invalid secret and credentials.įor the second piece you asked me to run manually I get some strange hex(?) back: *19da *19db *19ed *19fe The first IP address is the target VPN and the second is my Cell phone IP. I am unclear where the L2 report is coming from.? Note: I deleted the previous phase1 entries form the FW address-list. Terminal L2: failure: already have such entry Terminal L1: script=IPSEC_failed src_ip=phase1ģ. dynamically created a FW address-list rule named IPSEC with and address of phase1. Hi - Here is what happens with the first part -ġ. \n\t:log info message=\"script=IPSEC_failed src_ip=\$ip\"\r\ \n\t/ip firewall address-list add address=\$ip list=IPSEC timeout=24h\r\ \n:local loglist - 5m) message~\"negotiation failed\"]]\r\ \n# Find all \"negotiation failed\" error last 5 min\r\ \n# It should run on all routerOS version\r\ \n# Schedule the script to run every 5 min\r\
\n# This script add ip of user who failed IPSEC negotiation to a block list for 24hour\r\ Code: Select all /system script add dont-require-permissions=no name=Find_IPSEC_negotian_failed owner=jotne policy=\įtp,reboot,read,write,policy,test,password,sniff,sensitive,romon source="# Created Jotne 2019 v1.0\r\
0 kommentar(er)
