NethServer Version: 7.9.2009
Module: SOGo
Hello,
My Nethserver is DC for a windows domain. It does some file sharing and hosts SOGo. It has worked successfully for about 1 year. The user’s use Thunderbird to sync with SOGo through cal/card dav. As of about a week ago the phones (android and iphones) will not update their calendar/contacts to SOGo. The internal/green network still functions properly.
My setup: I have an IPFire firewall/proxy setup with red(internet), green(lan), orange(dmz), it is also running openVPN and my openvpn clients can still connect and have access to resources as if they were on the lan. Nethserver has red and green interfaces I also setup letsencrypt. I connect the orange ipfire to the NS red interface and green to green. I port forward http traffic to the green network. I port forward the https traffic to the orange network and then on to the NS red interface. I can reach my default NS webpage hosted on port 80. The default of Apache is being used. I cannot reach my webpage by https. This may not be the best way but it was the only way I could figure out.
I first thought it was a firewall issue but after checking the logs and running tcpdump on each interface it seems to be getting through the IPFire dmz and I can see the sync packet when I tcpdump on the eth0 and eth1 interfaces of NS. My knowledge of tcpdump and packet analyzation is extremely little, so I could be interpreting it wrong. I feel like the problem lies with NS somewhere. Possibly with apache. But I am reaching the limit of my ability.
I inherited this job after the gentleman I used for tech services past away. He introduced my to Linux and I’ve been setting up Linux boxes and learning what I can for about 4 or 5 years. I will do the best I can to answer any other questions, but it may take a bit if I have to research the question to understand it.
Thank you all.
Hi,
and welcome to the NethServer community.
Are there errors in the logfiles /var/log/messages or /var/log/sogo/* ?
2022-10-27 13:57:34.038 sogod[1570:1570] ERROR(-[NGLdapSearchResultEnumerator nextObject]): does not support result references yet ..
Oct 27 13:57:34 sogod [1570]: 192.168.16.155 "PROPFIND /SOGo/dav/huck HTTP/1.1" 401 0/187 0.072 - - 0 - 15
Oct 27 13:57:34 sogod [1570]: <0x0x564cb3e69e90[LDAPSource]> <NSException: 0x564cb42731c0> NAME:LDAPException REASON:operation bind failed: Invalid credentials (0x31) INFO:{"error_code" = 49; login = "samaccountname=huck,dc=ad,dc=boswellcontracting,dc=com"; }
Oct 27 13:57:34 sogod [1570]: 192.168.16.155 "PROPFIND /SOGo/dav/huck HTTP/1.1" 207 471/187 0.105 - - 0 - 16
Oct 27 13:57:34 sogod [1570]: 192.168.16.155 "PROPFIND /SOGo/dav/bos_sogo/calendar-proxy-write/ HTTP/1.1" 403 0/165 0.002 - - 0 - 15
Oct 27 13:57:34 sogod [1570]: 192.168.16.155 "PROPFIND /SOGo/dav/huck/Calendar/ HTTP/1.1" 207 990/320 0.005 7056 85% 0 - 15
Oct 27 13:57:34 sogod [1570]: 192.168.16.155 "PROPFIND /SOGo/dav/huck HTTP/1.1" 401 0/193 0.001 - - 0 - 15
Oct 27 13:57:34 sogod [1570]: 192.168.16.155 "PROPFIND /SOGo/dav/huck HTTP/1.1" 207 478/193 0.003 - - 0 - 15
Oct 27 13:57:34 sogod [1570]: 192.168.16.155 "PROPFIND /SOGo/dav/bos_sogo/calendar-proxy-write/ HTTP/1.1" 403 0/171 0.002 - - 0 - 15
Oct 27 13:57:34 sogod [1570]: 192.168.16.155 "PROPFIND /SOGo/dav/huck/Contacts/ HTTP/1.1" 207 573/123 0.005 3477 83% 0 - 15
This is from SOGo log. I ran a sync from Thunderbird, locally, which works. I then ran one from my phone on the mobile network and nothing showed up. Like SOGo never saw it.
This is from var/log/messages.
Oct 27 13:57:05 ns cockpit-session: pam_ssh_add: Failed adding some keys
Oct 27 13:57:05 ns systemd-logind: New session 2756 of user root.
Oct 27 13:57:05 ns cockpit-ws: logged in user session
Oct 27 13:57:05 ns cockpit-ws: New connection to session from 192.168.16.156
Oct 27 13:57:06 ns dbus[749]: [system] Activating via systemd: service name='org.freedesktop.timedate1' unit='dbus-org.freedesktop.timedate1.service'
Oct 27 13:57:06 ns systemd: Starting Time & Date Service...
Oct 27 13:57:06 ns dbus[749]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service'
Oct 27 13:57:06 ns systemd: Starting Hostname Service...
Oct 27 13:57:06 ns dbus[749]: [system] Successfully activated service 'org.freedesktop.timedate1'
Oct 27 13:57:06 ns systemd: Started Time & Date Service.
Oct 27 13:57:06 ns dbus[749]: [system] Successfully activated service 'org.freedesktop.hostname1'
Oct 27 13:57:06 ns systemd: Started Hostname Service.
Oct 27 13:57:06 ns dbus[749]: [system] Activating via systemd: service name='org.freedesktop.realmd' unit='realmd.service'
Oct 27 13:57:06 ns systemd: Starting Realm and Domain Configuration...
Oct 27 13:57:06 ns dbus[749]: [system] Successfully activated service 'org.freedesktop.realmd'
Oct 27 13:57:06 ns systemd: Started Realm and Domain Configuration.
Oct 27 13:57:06 ns cockpit-bridge: No entry for terminal type "unknown";
Oct 27 13:57:06 ns cockpit-bridge: using dumb terminal settings.
Oct 27 13:57:10 ns cockpit-ws: New connection to session from 192.168.16.156
Oct 27 13:57:10 ns cockpit-bridge: No entry for terminal type "unknown";
Oct 27 13:57:10 ns cockpit-bridge: using dumb terminal settings.
Oct 27 13:57:23 ns dnsmasq-dhcp[1131]: DHCPREQUEST(br0) 192.168.16.112 e6:af:0c:1d:c9:d0
Oct 27 13:57:23 ns dnsmasq-dhcp[1131]: DHCPACK(br0) 192.168.16.112 e6:af:0c:1d:c9:d0
Oct 27 13:57:33 ns kernel: IPv4: host 192.168.16.151/if4 ignores redirects for 162.125.6.20 to 192.168.16.1
Oct 27 13:58:09 ns dnsmasq-dhcp[1131]: DHCPREQUEST(br0) 192.168.16.112 e6:af:0c:1d:c9:d0
Oct 27 13:58:09 ns dnsmasq-dhcp[1131]: DHCPACK(br0) 192.168.16.112 e6:af:0c:1d:c9:d0
Oct 27 13:58:23 ns kernel: IPv4: host 192.168.16.112/if4 ignores redirects for 17.167.200.70 to 192.168.16.1
Oct 27 14:01:04 ns cockpit-bridge: No entry for terminal type "unknown";
Oct 27 14:01:04 ns cockpit-bridge: using dumb terminal settings.
Oct 27 14:01:11 ns kernel: IPv4: host 192.168.16.151/if4 ignores redirects for 70.32.23.94 to 192.168.16.1
Oct 27 14:02:10 ns cockpit-ws: WebSocket from 192.168.16.156 for session closed
Oct 27 14:02:10 ns dbus[749]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service'
Oct 27 14:02:10 ns systemd: Starting Hostname Service...
Oct 27 14:02:10 ns dbus[749]: [system] Successfully activated service 'org.freedesktop.hostname1'
Oct 27 14:02:10 ns systemd: Started Hostname Service.
Oct 27 14:02:10 ns cockpit-bridge: No entry for terminal type "unknown";
Oct 27 14:02:10 ns cockpit-bridge: using dumb terminal settings.
Oct 27 14:02:13 ns cockpit-ws: New connection to session from 192.168.16.156
Oct 27 14:02:38 ns kernel: IPv4: host 192.168.16.100/if4 ignores redirects for 17.253.24.125 to 192.168.16.1
Oct 27 14:03:04 ns nmbd[1143]: [2022/10/27 14:03:04.604863, 0] ../../source3/nmbd/nmbd_browsesync.c:354(find_domain_master_name_query_fail)
Oct 27 14:03:04 ns nmbd[1143]: find_domain_master_name_query_fail:
Oct 27 14:03:04 ns nmbd[1143]: Unable to find the Domain Master Browser name BOSWELLCONTRACT<1b> for the workgroup BOSWELLCONTRACT.
Oct 27 14:03:04 ns nmbd[1143]: Unable to sync browse lists in this workgroup.
Oct 27 14:03:04 ns nmbd[1143]: [2022/10/27 14:03:04.604989, 0] ../../source3/nmbd/nmbd_browsesync.c:354(find_domain_master_name_query_fail)
Oct 27 14:03:04 ns nmbd[1143]: find_domain_master_name_query_fail:
Oct 27 14:03:04 ns nmbd[1143]: Unable to find the Domain Master Browser name BOSWELLCONTRACT<1b> for the workgroup BOSWELLCONTRACT.
Oct 27 14:03:04 ns nmbd[1143]: Unable to sync browse lists in this workgroup.
Oct 27 14:03:42 ns sshd[13627]: Accepted keyboard-interactive/pam for root from 192.168.16.156 port 20283 ssh2
Oct 27 14:03:42 ns systemd-logind: New session 2764 of user root.
Oct 27 14:03:49 ns dnsmasq-dhcp[1131]: DHCPREQUEST(br0) 192.168.16.112 e6:af:0c:1d:c9:d0
Oct 27 14:03:49 ns dnsmasq-dhcp[1131]: DHCPACK(br0) 192.168.16.112 e6:af:0c:1d:c9:d0
Also, the server had been running for about 66 days from my last reboot. I may have done an update during that period. (I was still on 7.9.2009) I had rebooted the server just before I noticed this happening.
After rereading I think you just need to port forward both ports, 80 and 443 to the NethServer to make DAV work from WAN side.
I believe that I have sir.
I can reach the default NS page from port 80 over the external network.
The source address highlighted is my cell trying to connect over the external mobile network.
To just make it work you could configure the https port forward like the http one.
Why the forwards are directed to two different zones and two different IP address?
192.168.16.2 for port 80
192.168.6.2 for https (should be 443 but whatever)
Also: is there a chance that Nethserver on its own Green interface is having IPFire as gateway? (AFAIK, with the Nethserver RED zone connected to IPFire Orange zone should not happen… NethServer must use only RED adapter to access internet)
Sorry for the delay. I wanted to attempt a network diagram.
I hope this provides more clarity than confusion, my first attempt at making one.
@mrmarkuz I did configure the port forward of 443 traffic to the green network and as expected it just works. However, does this negate any protections that the dmz provides. ( I tried to recreate what my previous IT guy had set us up, it was actually IPCop to a Windows server vm.)
@pike Nethserver green is using Ipfire as gateway.
Thank you both for your time.
IMHO it should not.
Nethserver should use only RED interface for connect to internet, not have a gateway on green (so routing table will use RED interface as main route unless toward green).
And port forward from IPFire red (only) should lead only to orange zone, NethServer RED IP address.
In this situation, as far as i can imagine, the thing goes like this.
-outside device knock to port 443 of IPFire Red.
-according to port forward, it’s delivered to NethServer RED interface.
-then Nethserver answers… via default route, the GREEN Interface.
-Ipfire receive traffic on its green interface; there’s no matching data request, so it forwards all answers to /dev/null.
-outside device got stuck in the dark with no answers
IMVHO you should.
- backup both IPFire and NethServer configuration. Better safe than sorry, or BBB (Backup Before Begin)
- change all port forwarding for NethServer on IPFire, from Red to green, to red to Orange
- brew some excellent tea, infusion, the think you like most. Alcool not best option
- remove IPfire IP address as NethServer Gateway
- Bat out of the hell about any traffic from NethServer to internet, taking a thorough read of both IPFire and NethServer logs, than create all the traffic rules you need to get NethServer working using only RED/Orange interface. Because of the design of DMZ/Orange, usually what’s not explicity allowed is blocked, so the log reading, the rule building, the rule testing (with torough reading and so on) will take time, energy, patience and… wash, rinse, dry, repeat. Quite a lot.
It’s quite hell of a job to do short rule list for orange/DMZ. A simple rule “allow everything” however it will blow up the concept of DMZ and it works but I’m not suggesting to do that at all.
First thing to take note is what the services (ports) are gonna be used from internet, then write service group.
Second one is what services will nethserver need… And if your setup does most internet services and not local one (CUPS, SMB, backup) maybe have NethServer with one green interface but in Orange Ipfire is a better solution.
Hell of a job to workout the whole list of services for IPFire green, but after that, the list for Red is quite a joke…
@pike Thank you sir. I will give it a try. I may have some questions once I get started. When I first put this together I tried to copy what was done previously, but I seem to have screwed that up. What’s strange is that it did work for about a year, I haven’t made any changes to the network or routing in that time… I’m very confused as to what happened… lol
Don’t forget http/port 80, or Certbot won’t like at all your server…
I’m up and running.
Thank you!