-A backend is where all the weird c++ language stuff happens to generate a response from an AI. -a front end is a pretty app or webpage that takes that response and make it more digestible to the user.

Yes.

-agreed. I’ve seen in other posts that exposing a port on windows defender firewall is the easiest (and safest?) way to go for specifically what I’m looking for. I don’t think I need to forward a port as that would be for more remote access.

Yes. I’d like to confirm that that is not happening, in fact.

The ipv6 was identical to one of the ones I have.

Hmm. Okay, thanks for mentioning the IPv6 thing. It is possible to have ollama reachable from the Internet via IPv6, if it’s forwarded. I should have thought of that too and mentioned that. Shouldn’t need to open an IPv6 hole in the Windows Firewall, but would rather not rely on the Windows Firewall at all.

It shouldn’t be an issue if ollama is only listening on an IPv4 address. You only see the “0.0.0.0:11434” line, right? No other lines, probably with brackets in the address, that have a “:11434”, right? That could be an IPv6 address.

goes to look for an example of Windows netstat output showing a listening IPv6 socket

Here:

https://www.configserverfirewall.com/windows-10/netstat-command-to-check-open-ports-in-windows/

Can you just make sure that there’s nothing like 0:[::]:11434 in there? That’d be what you’d see if it were listening for IPv6 connections.

Sorry, just don’t know oollama’s behavior off the top of my head and want to be sure on this before moving ahead, don’t want to create any security issues.

The ipv4 was not identical. (But I don’t think that matters moving forward.)

Yeah, that’s expected and good. The one from the website is your public IP address, anf the one from ipconfig your private one, that you’ll use to talk to the machine wirh your phone.

I had to go into the settings in the ollama backend app to enable “expose Ollama to the network”.

Great, yeah, that was the right move.

Okay, then just want to sanity check that your iOS device is in the same address range on your WiFi network, that the 10.x.x.x address on your LLM PC isn’t from a VPN or something (since it’s a little unusual to use a 10.x.x.x address on a home broadband router, and I want to make sure that that’s where the address is from). Go ahead and put the iOS device on your WiFi network if you have not already.

This describes how to check the IP address on an iOS device.

https://servicehub.ucdavis.edu/servicehub?id=ucd_kb_article&sys_id=063498196f082100bc4f8a20af3ee45d&spa=1

You should also be seeing a 10.x.x.x address there. If you don’t, then let’s stop and sort that out.

If that’s a 10.x.x.x address as well, then should be good to go.

Oh, one last thing. In the ipconfig output, can you make sure that the “Subnet Mask” reads “255.0.0.0”? If it’s something different, can you provide that? It’ll affect the “/8” thst I’m listing below.

Okay, if you’ve got that set up and there are no other “:11434” lines and the Subnet Mask is “255.0.0.0”, the next is to poke a hole in Windows Firewall on IPv4 TCP port 11434.

kagis for screenshots of someone doing this on Windows 11

https://windowsreport.com/windows-firewall-allow-ip-range/

I’m assuming that this is Windows 11 on your PC, should have asked.

You’re going to want a new inbound rule, Protocol TCP, Port 11434.

For “local IP addresses”, you want “These IP Addresses”, and enter 10.0.0.0/8. That’ll be every IPv4 address on your Windows LLM that has “10” as its first number — you said that you had a “10.” from ipconfig.

For “remote IP addresses”, you want “These IP Addresses”, and enter 10.0.0.0/8. Same thing all addresses that start with a “10.”, which should include your iOS device.

And you want to select “Allow this connection”.

Okay. Now you should have a hole in Windows Firewall. Just to confirm that port 11434 isn’t reachable from the Internet, I’m gonna use one of the port-open-testing services online. My first hit is for one that only does IPv4 and another that only does IPv6, but I guess doing two sites is okay. Can you go to this site (or another, if you know of a site that does port testing that you prefer)

https://www.yougetsignal.com/tools/open-ports/

Plug in your public IPv4 address there (not the private one from ipconfig, the one from that website thst I listed earlier) and port 11434. It should say “closed” or “blocked” or something that isn’t “open”. If it’s “open”, go back and pull that firewall rule out, because your router is forwarding incoming IPv4 connections to your LLM PC in some way that’s getting to ollama, and we gotta work out how to stop that.

https://port.tools/port-checker-ipv6/

Here’s an IPv6 port tester. Plug in your IPv6 address there (which you said was the same from both the website and ipconfig) and port 11434. It should also say “closed” or “blocked” or similar. If it says “open” — I very much doubt this — then go back and pull out the firewall rule.

If both say “closed”, then go ahead and install Reins.

Based on this:

https://www.reddit.com/r/ollama/comments/1ijdp1e/reins/

It’ll let you input an “endpoint”.

Plug in the private IPv4 address from your LLM PC, what was in ipconfig, in the form of an http URL on the ollama port, like “http://10.something.something.something:11434/” and you should, hopefully, be able to chat.

If all this is working and you’ve given your Windows PC a name, you might want to go back to that endpoint setting and replace the IP address there with the name of your LLM PC. I don’t know for sure what the mDNS situation is on iOS or Windows, but if that works, that way, if your Windows PC loses its DCHP lease and gets a new IP address at some point from your broadband router, it won’t break connectivity for Reins as Reins tries to use the old IP address.