So I have my XMPP server on an inside subnet, and I've got the port forward working...at least from the outside. I'm hoping someone can help me out with a weird issue though.
So outside my LAN, people can reach my chat server and authenticate using the DDNS I have setup. No issue there. However, from inside the LAN I can't use the DDNS address. I have to specify the internal IP of the server to use the chat when I'm at home. I can only assume this has something to do with the port forwarding, but I'm not sure what it would be.
I already have "Reflection for port forwards" and "Automatic outbound NAT for reflection" enabled globally in the system > advanced settings, and I also have it enabled explicitly on the port forward rule
Are you using Unbound DNS? If so you can do an Override. I've had to do something similar for a server that worked fine outside my LAN but inside my lan the firewall got "confused" about routing it. Once I added the server to the Override so internal DNS resolved properly it was fine.
It's enabled but I haven't messed with it yet because I wasn't exactly sure what it was for. Is it just a DNS service provided by the firewall?
It is, but has alot of functionality. I use it for my DNS.. so my DDNS ip was resolving to the real world ip and I think it was getting lost in translation.. so I've set an override up that points the ddns name to the local internal IP for anything on the LAN and it works great.
Sorry for slightly OT, but do you have a link for a tut you used for setting up the XMPP server? Do you use TLS? Many thanks in advance!
@cguilford - Do you mind sharing a screen shot or maybe a quick run down of how you did that? Just so I don't make things worse haha
@chemlud - I just use openfire server and pidgin is the chat client. It's just to talk with some family/friends back in NY. It's pretty easy to setup initially. I haven't really messed with TLS on it though.
@loganx1121 - it's pretty straight forward here is a screenshot of what mine looks like. If that doesn't help let me know I can walk you through it.
Quote from: loganx1121 on October 17, 2019, 03:52:17 PM
@cguilford - Do you mind sharing a screen shot or maybe a quick run down of how you did that? Just so I don't make things worse haha
My firewall and none of the clients are in a domain...does that matter?
@cguilford I tried it just using the domain of the DDNS url but it didn't work. None of the LAN clients are setup to use the firewall for DNS either.
Also here's a pcap in wireshark filtered by destination port 5222 which is what the XMPP server uses.
Ahh if they are not using the opnsense box for DNS then I'm not sure what else you can do? Short of modifying a host file on the PC side to point the dns name to the internal IP of the XMPP server. I'm not sure how many pc's you have, you could also maybe, if you are using Internal DNS on another server make a similar change to the DNS records on the DNS server itself to point to the internal IP.
Yeah I'm not using anything for internal DNS. It's just a home lab. I had planned on building a DNS server but I wanted to get the firewall and chat server all situated first. I'm considering using the firewall for internal DNS, and also for DHCP. Right now DHCP is running on my layer3 cisco core switch.
It'd be better if the NAT reflection just worked. I kind of suck with wireshark though.
The problem you are having is that your using external DNS to resolve the host which is your WAN IP, when the LAN side hits that the FW isn't capable of transfersing from LAN -- > WAN --- Back to LAN and make the port forward work if that makes any sense. If you use Opnsense as DNS and such, IE I use it for DNS and DHCP, you can set up the override and the LAN side see's the override and points back into the LAN and never transverses out to the WAN to try to come back in.
I suppose that makes sense. It's making me wonder how my Asus router did it though when I had that as the edge router. Maybe this is one of those things where I got something much more complex and things I used to take for granted just don't work the same.
Solved - I was able to resolve this by adding an outbound NAT rule to my LAN interface. Still means NAT reflection isn't working properly, but I was able to work around it...