Multiple Ports on internal webserver some not working.

I just put our internal network behind a T25. Working out a few bumps. Main problem right now is our internal webserver running IIS. Ports 80,443 working just fine. Also have a port 8443 using a different cert that I am not able to access internally. From any machine on the network browsing server ip on https or http working fine. Using 8443 times out. Also i am running an application called Miva Mia. It is a temporary webserver running on port 9000. Confirmed server is listening on all ports. All of this was working before I made the switch so i am sure it is my lack of knowledge. My questions are. Should there be a need to have an explicit firewall allow policy from trusted to trusted on a specific port? Lastly is there a possibility the WG is blocking the Mia.exe application blocking access to that port somehow?


  • By default, no packets can cross a routed interface without a policy allow that access - including from 1 trusted interface to another trusted interface.

    Traffic Monitor should show and denied packets, and includes the source IP addr, the dest IP addr and the protocol, source port and dest port of the packet.

    You can allow all packets from 1 trusted interface to another trusted interface if so wanted by using an Any policy From: Any-trusted To: Any-trusted.

    Or you can add specific policies.
    For ports for which there is not a predefined policy, you can create Custom packet filters and then use them to create policies.

    Create or Edit a Custom Policy Template

  • Thanks for your response Bruce. Everything currently is on one trusted interface. So it should not be sending packets across trusted interfaces. Also i created a custom http proxy policy on port 9000 that allows Any-Trusted to Any-Trusted and I am still unable to reach port 9000. If i am not sending across interfaces would it show an allow or deny in the traffic monitor?
    This is looking more like an issue on my server rather than the WG.

  • Please explain "before I made the switch" - from what - to what.

    If everything is on the same firewall interface AND is part of the same subnet, then packets from 1 device on the firewall interface to another device on the same interface does not go via the firewall - it goes directly using Ethernet.

  • What is the IP addr & subnet mask of the server and of a PC where the 8443 access times out?

  • Maybe you could answer one more question Bruce. Would the WG have anything to do with TCP retransmissions of SYN packets? I did a wireshark capture of this issue and its littered with retransmission when i am having this problem.

    4743 42.374533 TCP 66 [TCP Retransmission] 53071 ? 9000 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM
    4746 42.637990 TCP 66 [TCP Retransmission] 53072 ? 9000 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM
    4913 44.384658 TCP 66 [TCP Retransmission] 53071 ? 9000 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM
    4949 44.649647 TCP 66 [TCP Retransmission] 53072 ? 9000 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM

  • Before i made the switch, upgraded standard router (Netgear) with Firebox T25. Ip address of server is ,, Pc,

  • Retransmissions suggest that the dest IP addr is not replying.
    SYN is the TCP session initiation flag.

    Those packets should be going directly between each 192.168.1.x/24 device and not via the firewall.

    Try a power off/on of the switch(es) to which the 192.168.1.x/24 devices are connected, and see if that changes anything.

    How have you confirmed that the server is listening on all ports? Testing from other devices doesn't seem to confirm this.

  • I have run a netstat on it and the port is listening. Also i can physically open a browser on the server and load pages using the ports.

  • I will try and reset the device when the ladies go to lunch. I might not be able to because we have someone remoting in from Alaska. So i might have to wait till everyone leaves for the day.

  • Ok i was able to reboot and there is no change.

  • Try running a packet capture on your server.

    Other than that - no more thoughts.

  • Ran one. Was pretty much the same. Found the issue though. When the server connected to the WG it changed for some reason to being on a public or guest network. I dont know how or why. The application did not have a firewall record on the server for public networks. Thus blocked. Thanks for your help Bruce!

Sign In to comment.