PF_KEY message
-
So nothing has tried to start the tunnel up. Do you have keep-alive addresses set on either end of the tunnel?
Have you tried to initiate a ping from one client LAN to the other side?
Or from pfSense on the console, see the lower part of this page.
-
keep-alive is set, its the gateways lan at the other end
ping fails (time out)
looking at page now.page didnt help.
-
i had to forcefully reload the tunnel and its onto phase 2
i get:
Dec 16 20:27:07 racoon: ERROR: failed to pre-process packet.
Dec 16 20:27:07 racoon: ERROR: failed to get sainfo.
Dec 16 20:27:07 racoon: ERROR: failed to get sainfo.the above keeps repeating for about 3 times and then this:
ERROR: x.x.x.x give up to get IPsec-SA due to time up to wait.
-
heres my logs, they repeat
Dec 16 21:11:24 racoon: [Site-Site VPN Tunnel]: ERROR: RemoteWANIP give up to get IPsec-SA due to time up to wait
Dec 16 21:11:05 racoon: ERROR: failed to pre-process packet.
Dec 16 21:11:05 racoon: ERROR: failed to get sainfo.
Dec 16 21:11:05 racoon: ERROR: failed to get sainfo.
Dec 16 21:11:05 racoon: [Site-Site VPN Tunnel]: INFO: respond new phase 2 negotiation: WANIP[0]<=>WANIP[0] -
Are you sure that IPsec traffic is able to reach both routers? The logs seem to imply a lack of communication or timeout, as if the traffic is being blocked or going to the wrong IP address(es).
-
I had a site-site vpn setup before, that was with openvpn using client -> server. dont know if its been changed but at the time, one had to know the exact ip of the server.
but those logs say that its not connecting? I will check with my isp (one is qwest (they dont block anything) other is cox (they block but dont say what, will only say after you tell them what our trying to do and you have to call corporate, will elaborate if anyone wants to know more)
-
With IPsec on 1.2.3 you can use hostnames for the remote peer, so it shouldn't be a problem to use dyndns there if you don't know the exact IP.
You could do some tcpdump/packet captures on the WAN of both sites to see if you are receiving any traffic. There is a bit about that kind of troubleshooting in the book.
-
heres the dump log
12:53:59.308806 IP y.y.y.y.500 > x.x.x.x.500: UDP, length 292
12:53:59.337224 IP x.x.x.x.500 > y.y.y.y.500: UDP, length 316
12:53:59.457402 IP y.y.y.y.500 > x.x.x.x.500: UDP, length 52
12:53:59.459263 IP y.y.y.y.500 > x.x.x.x.500: UDP, length 84
12:54:00.496691 IP y.y.y.y.500 > x.x.x.x.500: UDP, length 300
12:54:10.495514 IP y.y.y.y.500 > x.x.x.x.500: UDP, length 300
12:54:20.497094 IP y.y.y.y.500 > x.x.x.x.500: UDP, length 300
12:54:51.497879 IP x.x.x.x.500 > y.y.y.y.500: UDP, length 92
12:54:56.498759 IP x.x.x.x.500 > y.y.y.y.500: UDP, length 92
12:55:01.499686 IP x.x.x.x.500 > y.y.y.y.500: UDP, length 92
12:55:06.503968 IP x.x.x.x.500 > y.y.y.y.500: UDP, length 92
12:55:11.507307 IP x.x.x.x.500 > y.y.y.y.500: UDP, length 92
12:55:59.341119 IP y.y.y.y.500 > x.x.x.x.500: UDP, length 92
12:55:59.341697 IP x.x.x.x.500 > y.y.y.y.500: UDP, length 92
12:55:59.341928 IP x.x.x.x.500 > y.y.y.y.500: UDP, length 92
12:55:59.433219 IP y.y.y.y.500 > x.x.x.x.500: UDP, length 92with regards to the book, i am getting it, its on order from amazon i just have to wait.
-
That's all you see with tcpdump? Or was that a packet capture from the GUI?
Usually tcpdump will do some protocol analysis on IPsec, and it will look more like:
14:01:24.566352 IP x.x.x.x.500 > y.y.y.y.500: isakmp: phase 1 I agg
14:01:24.623288 IP y.y.y.y.500 > x.x.x.x.500: isakmp: phase 1 R agg
14:01:24.653504 IP x.x.x.x.500 > y.y.y.y.500: isakmp: phase 2/others -
you are correct, that was just a packet capture.
i will do a tcpdump and post results when i can access the other system -
well, I think it may be cox or my modem. If i cant find one for cheap I will be switching to qwest, i have them at another location and they have been very reliable. Cox doesnt even know how much they sell the motorola modems for, i have been told 30-60.
when pinging location 1, i would get 1 response for every 10-20 pings. connection keeps getting dropped with no activity at the location and it goes away for several hrs. but after looking at the modems logs it looks as if it is getting the wrong info from cox, one entry will have the correct timestamp then the net will have 1970 and a level 3 error (mostly dhcp, or oid response errors) then the next couple have the correct timestamp.
-
well i swaped the modem, that helped with the connectivity issues but not the vpn, there is no data for port 500, the ssh and other web stuff is there but no port 500 or any isakmp stuff
-
i will try to redo the site to site following your instructions in the book either later today or tomorrow
-
well, i rebuilt the vpn and now it is working.
Thanks for all your help.
The book is very helpful, who do i contact about errors? (is there a central place to do it?) Most can be solved by reading the entire section (the subnetmask.info topic is one example)
-
Good to hear it's working. There is an errata page here:
http://www.reedmedia.net/books/pfsense/errata.html
Check there first, and if it's not a known error, they can be sent to me (jimp (a) pfsense.org) or Chris (cmb (a) pfsense.org) and we'll see what can be done about them.
