It is what I have anticipated. The Fortigate administrator expects that every device in the world behaves like his Fortigate, so he does not even dream that forcing people into use of a policy which matches on all traffic can cause trouble on the clients' side.
To work this around, you will need a pile of action=none
policies which will match on packets which should not get to his network, so that only what will get through all those policies unmatched would finally hit that 0.0.0.0/0->0.0.0.0/0 policy and get to him. To make it simpler, I'll show you the method on the first two bytes of the IP address. I hope you are familiar with the conversions between binary and decimal notation and the IP mask construction principle.
So let's say the first two bytes of the b.b.b.b are 217.125. This, in binary, is 1101 1001 0111 1101. So we have to go bit by bit and create all the prefixes of different lengths from 1 to 32 which match this value in all their bits except the last one:
prefix table code
1101 1001 0111 1101
0... .... .... .... => 0.0.0.0/1
10.. .... .... .... => 188.8.131.52/2
111. .... .... .... => 184.108.40.206/3
1100 .... .... .... => 192.0.0.0/4
1101 0... .... .... => 220.127.116.11/5
1101 11.. .... .... => 18.104.22.168/6
1101 101. .... .... => 22.214.171.124/7
1101 1000 .... .... => 126.96.36.199/8
1101 1001 1... .... => 188.8.131.52/9
1101 1001 00.. .... => 184.108.40.206/10
1101 1001 010. .... => 220.127.116.11/11
1101 1001 0110 .... => 18.104.22.168/12
1101 1001 0111 0... => 22.214.171.124/13
1101 1001 0111 10.. => 126.96.36.199/14
1101 1001 0111 111. => 188.8.131.52/15
1101 1001 0111 1100 => 184.108.40.206/16
So for the actual address b.b.b.b, you have to calculate all the 32 prefixes of non-matching subnet the way above, and use each of them as dst-address
of an /ip ipsec policy action=none
placed above the single policy with action=encrypt dst-address=0.0.0.0 required by the Fortigate. The good point is that if you go this way, you can remove the previously added policy with action=none
as one of those will substitute it.
But there may be a much easier way which you should try first. The guy asks you to send him packets with a public address as a source one, and the reason is that he needs to be sure that two clients won't send him packets from the same address, so that the Fortigate knew where to route the responses. But it does not necessarily need to be the same public address from which you establish the tunnel.
So do the following - keep the configuration with just the two policies we had yesterday, action=none src-address=0.0.0.0/0 dst-address=192.168.0.0/24
and action=encrypt src-address=0.0.0.0/0 dst-address=0.0.0.0/0
, and put above the action=encypt
one yet another action=none
one with src-address=your.wan.ip.address dst-address=0.0.0.0/0
This will make the tunnel establish successfully but will prevent anything from being sent through it, because whatever you send outside your LAN is first src-nated to your WAN public address.
Now take some public IP address which you control and are sure that it won't ever connect to that Fortigate's VPN, say, m.m.m.m, and add the following rule above the currrent action=masquerade
rule you use in /ip firewall nat chain=srcnat
/ip firewall nat add chain=srcnat action=src-nat dst-address=b.b.b.b to-addresses=m.m.m.m
So the source address of packets you sent to b.b.b.b will be translated to m.m.m.m, so the second policy with action=none
will ignore them, and the action=encrypt
policy will match them and send them to the Fortigate.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.