IPsec + Cisco Meraki
-
Hello guys,
Little bit stuck here... what I am trying to achieve is to connect office subnet with one of the subnets in cloud (VPC).
Generally from IP point of view it looks like this
192.168.101.101<-LAN-to-WAN->93.189.254.11<-WAN-to-WAN->80.159.40.151<-NAT->172.28.28.28<-VPC peering->192.168.34.180
192.168.101.101 is source server in office that should be able to connect to 192.168.34.180 using https which is destination server in cloud .
93.189.254.11 is Cisco Meraki
80.159.40.151<->172.28.28.28 is Pfsense which is installed in cloud. WAN interface is 172.28.28.28 and public IP 80.159.40.151 is added by hoster via NAT I guess. It is not dirrectly addigned to the pfsense server.I have made a connection in IPsec and looks like it is working because I can ping 172.28.28.28 from 192.168.101.101 and vise-versa. BUT I cannot ping 192.168.34.180 from 192.168.101.101 which is the goal.
routings between 172.28.28.28 and 192.168.34.180 are being handled using so called VPC peering at hoster end.
And actually I can achieve the goal by making a simple openVPN connection from 192.168.101.101 through pfsense which is working fine but I do not want to boot it up all the time manually on each 101 network machine that can be created in future. Thus decided to make a client/peer VPN connection from cisco... then understood that on Meraki IPsec supported only... thus need to make it through IPsec.If anyone can help this would be great. For me it sounds like some how I need to make IPsec to pass packets further from 172.28.28.28 ...
IPsec status look like this
-
And additional info. After some investigation I can see that packets are coming fine to destination but does not return back sucecssfully.
On pfsense end on connection state I can seeIPsec tcp 192.168.101.101:50776 -> 192.168.34.180:443 CLOSED:SYN_SENT
On target machine using tcpdump I can see
# tcpdump -n -vv host 192.168.101.101 tcpdump: listening on ens3, link-type EN10MB (Ethernet), capture size 262144 bytes 14:21:40.049054 IP (tos 0x10, ttl 62, id 13517, offset 0, flags [DF], proto TCP (6), length 60) 192.168.101.101.57472 > 192.168.34.180.22: Flags [S], cksum 0x6708 (correct), seq 98888915, win 64240, options [mss 1460,sackOK,TS val 1943639925 ecr 0,nop,wscale 7], length 0 14:21:40.049108 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) 192.168.34.180.22 > 192.168.101.101.57472: Flags [S.], cksum 0x0798 (incorrect -> 0xfc38), seq 543160025, ack 98888916, win 65160, options [mss 1460,sackOK,TS val 623782591 ecr 1943639925,nop,wscale 7], length 0 14:21:41.066452 IP (tos 0x10, ttl 62, id 13518, offset 0, flags [DF], proto TCP (6), length 60)
I am not very good in networking but this looks wrong, no?
cksum 0x0798 (incorrect -> 0xfc38)Do you think this could help?
-
I have solved the issue. The cause was on hoster's network and I had to manually add vpc routes to go via pfsense server for office networks CIDR.
Also need to add that there was no such issue when we for example use openVPN since it masks the IP and in normal IPsec we have to know exactly where to send packages to. Thus some extra steps have to be done.