I have those ports forwarded already on the Fios router. The rule is GRE, ESP, AH, UDP Any > 500, UDP Any > 4500 and UDP Any > 1701
on the Fios UI I went and set up the Tik as DMZ
If you have DMZ set for Tik's 192.168.x.x (internet-facing) address, there is no need to use port forwarding rules.
If you wouldn't use DMZ, out of all your port-forwarding rules only those UDP Any -> (500,1701,4500) would be necessary for L2TP over IPsec, as in this case, the L2TP is tunnelled inside ESP which itself is tunnelled inside UDP.
not sure what you mean by L2TP with use-ipsec=yes - when I google that I got some long scripting stuff from the Wiki that is past my knowledge
Well, I've used a scripting notation for an item which is available as a drop-down menu in WinBox (the application for Tik configuration) and WebFig (Tik's configuration web interface). So about L2TP/IPsec from scratch:
- unless you have some reason not to do so, remove any IPsec configurations you may have done, keep just the default ones in place (policy template & proposal), remove any peer eventually created; if you have a reason not to do so, say something about it
- go PPP->L2TP server, check the checkbox "Enabled", choose "required" in "Use IPsec" and fill in the "secret" accordingly. This will create a dynamic IPsec peer configuration with the necessary settings.
I went into Secrets on the UI...
I swapped out the server name (the cloud name I got from tik) for my IP address...
On the profiles on the secrets tab all I do is select enabled, add a username (Name), a password, a service...profile I leave as default, local address I put in the tik address that it is serving up (again the fios broadcasts 192.168.x.x. so the tik is at 192.168.x.x. but in this field I put in 10.13.x.x which is how I pull up the Tik UI),
for remote address I put in my public IP address
The first bold point - should not matter. I've just tested that Mikrotik's cloud DNS service registers the public address through which the Mikrotik is visible to the world, it just murmurs internally that the address differs from its own one so something may not work as expected.
The second bold point is wrong. The remote address is what will be assigned to the client once he authorizes. So you can either use the name of the dhcp pool matching the 10.13.x.x subnet, or a particular address from there.
I have RSA SecurID off, the password and secret on the iOS interface I believe is the same so I put the same thing down.
Wrong. The secret must match the one you have set at the L2TP server page of your Tik (must be the same at all your iPhones), while the password is the one you have set at the PPP secrets page individually per user (representing a device, i.e. each of your iPhones should use a different username and password, otherwise they would fight for the same address).
One more point - if you have configured a bridge for your 10.13.x.x subnet, double-check that Tik's IP address from this subnet is attached to the bridge, not to one of its member Ethernet interfaces. If it is not, change that. Then, go to the settings of the bridge and change the ARP setting from "enabled" to "proxy-arp".
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.