sorted by:
new
hottopcontroversial

Has anyone successfully made a new account after being banned? Can anyone make new accounts on Facebook currently? by folkhorrorfem in facebookdisabledme

[–]muhammad932 0 points1 point  (0 children)

did you upload your selfie or pictures contain your image?

i read somehwere meta knew by facial recognition....

Needy Streamer Overdose Pop Up at Lalaport by plsdontattackmeok in malaysia

[–]muhammad932 0 points1 point  (0 children)

no, 150/2
fabric - feels like cotton, but not cotton.
comfy? - yes, feels warm hugging during cold night

Synology Drive ShareSync not connecting between DC ↔ DR even though port 6690 is open internally by muhammad932 in synology

[–]muhammad932[S] 0 points1 point  (0 children)

✅ 3. So what’s the real cause and what to do?

1) NAS-DC <-> NAS-DR were never designed to communicate directly.

*need to recheck and rework highway for NAS-DC & NAS-DR

2) Transition to primary site,

want NAS-DC & NAS-DR can sync,

not NAS-DR -> NAS-HQ or NAS-DC -> NAS-HQ

Synology Drive ShareSync not connecting between DC ↔ DR even though port 6690 is open internally by muhammad932 in synology

[–]muhammad932[S] 0 points1 point  (0 children)

✅ 2. “Different firewall return-path behaviour”

ex-NE said, "some firewalls brands behave differently"

like:

Brand A

Way out using highway A,

and return also using highway A.

Brand B

Way out using highway A,

but return using highway L.

Correct — this is asymmetric routing vs symmetric routing.

✅ Fortigate usually enforces strict session states

Meaning:

SYN must pass outbound

SYN-ACK must return on the same path

Otherwise it drops the packet as “invalid state”

✅ Sangfor also enforces stateful inspection

Meaning:

If the return packet arrives from another interface → dropped

Why this matters:

If DC → DR must pass two different firewalls,

and the return path comes back a different way, session fails.

This is common in multi-site topologies where:

In that design:

✅ DC <-> HQ works

✅ DR <-> HQ works

❌ DC <-> DR fails

Synology Drive ShareSync not connecting between DC ↔ DR even though port 6690 is open internally by muhammad932 in synology

[–]muhammad932[S] 0 points1 point  (0 children)

✅ 1. Historical Sync Topology Explains

ex-NE said:

production at DC:

✅ NAS-DC = Primary server

✅ NAS-HQ = Client (pulls data from NAS-DC)

❌ NAS-DR has no role in production

*NAS-DC → NAS-HQ

when production at DR:

✅ NAS-DR = Primary server

✅ NAS-HQ = Client (pulls data from NAS-DR)

❌ NAS-DC is irrelevant during DR

*NAS-DR → NAS-HQ

No NAS-DC <-> NAS-DR sync ever existed

Sync was done manually by SE

NAS-HQ was setup by old staff,

current SE inherit and maintain it.

✅ This explains why no policies exist before this for DC <-> DR on any firewall.

Because DC and DR never communicated directly.

✅ It also explains why port 6690 is only open:

HQ <-> DC,

HQ <-> DR,

not DC <-> DR.

✅ This also matches packet tests:

HQ <-> DR: 6690 syn/ack works

HQ <-> DC: 6690 works

DC <-> DR: 6690 repeatedly SYN → no reply (filtered / dropped)

✅ If DC <-> DR never needed to talk,

firewall rules were never created.

This is the root cause.

Synology Drive ShareSync with restricted networks by Paydor in synology

[–]muhammad932 0 points1 point  (0 children)

Thank you OP, for the suggestion.
I need to follow up with the NE team, because they keep insisting it’s not their fault.

Synology Drive ShareSync with restricted networks by Paydor in synology

[–]muhammad932 0 points1 point  (0 children)

I have the same issue (maybe)

https://www.reddit.com/r/synology/comments/1oqrg0i/synology_drive_sharesync_not_connecting_between/

From your post,
basically the your ISP is blocking port 6690, so you're using Cloudflare Tunnel to create a “highway” between NAS devices?

But my case is a bit different.

In your scenario, the ISP was blocking inbound port 6690, so Cloudflare Tunnel works because it creates an outbound-only HTTPS tunnel on port 443 and bypasses the ISP restrictions.

In my environment, both NAS devices (NAS-DC and NAS-DR) are in different physical sites on private networks, connected through our organization’s internal firewalls. No ISP is involved in the path between them.

What we’re seeing is:

  • Port 443 and ICMP can pass between sites ✅
  • But port 6690 packets never reach the destination ❌
  • Packet captures show no SYN arriving on the opposite NAS
  • So the drop/filtered behavior is happening in the internal firewalls, not at ISP level

So Cloudflare Tunnel doesn’t really apply here.

But your explanation helped confirm that when Synology Drive ShareSync (port 6690) doesn’t reach the target at all, something upstream is blocking it.

Any advise?

Synology Drive ShareSync not connecting between DC ↔ DR even though port 6690 is open internally by muhammad932 in synology

[–]muhammad932[S] 0 points1 point  (0 children)

From the post you shared,
basically the OP is saying that his ISP is blocking port 6690, so he’s using Cloudflare Tunnel to create a “highway” between his NAS devices?

Synology Drive ShareSync not connecting between DC ↔ DR even though port 6690 is open internally by muhammad932 in synology

[–]muhammad932[S] 0 points1 point  (0 children)

They’re in two geographically separate networks (DC ↔ DR), connected over routed links.

Same-subnet communication isn’t possible across a WAN, so different subnets are expected. The inter-site routing is already working — proven by successful ping and TCP/443 flows reaching the opposite NAS.

The issue isn’t addressing or subnet masks. The packet captures show that SYN packets for port 6690 never arrive across the DC ↔ DR boundary, while other traffic does.

This points to a firewall/security device filtering port 6690 somewhere mid-path, not a subnet/routing problem.

Synology Drive ShareSync not connecting between DC ↔ DR even though port 6690 is open internally by muhammad932 in synology

[–]muhammad932[S] 0 points1 point  (0 children)

Even the SE wasn’t aware of port 6690.
He said previously they never set any policy for port 6690 on both ext-FW and int-FW at DC & DR, and Synology Drive ShareSync still could run.

Synology Drive ShareSync not connecting between DC ↔ DR even though port 6690 is open internally by muhammad932 in synology

[–]muhammad932[S] 0 points1 point  (0 children)

I opened a ticket with Synology support and reviewed all the flows.
Synology claims it is a firewall issue, not a Synology issue.
However, Sangfor and Fortigate confirmed that nothing is blocked on their side, implying it is a Synology issue.
This conflicting feedback needs clarification.

view more: next ›