Cannot forward port 80

ZartPARZ · Mon Apr 30, 2018 11:39 am

Hi,

I have problem forwarding port 80 to my home server.

On my server, I have apache running on port 80 and nginx running on port 40080.
On my router (RB3011) I forward port 20080 to port 80 on my server and port 40080 to 40080 on my server using dst-nat. These are working fine. I can access both apache and nginx from internet using port 20080 and 40080, respectively.

Then, I want to setup nginx as proxy. I try to forward port 80 on my router to port 40080 on my server, but I cannot access nginx. I try to forward port 80 to port 80 on my server, but I cannot connect to apache too.

What may be the cause? I have disabled the mikrotik web service. I try to disable hotspot. But all are not working.

Regards,
ZartPARZ

Sob · Mon Apr 30, 2018 5:48 pm

If you successfully forwarded two ports, it's likely that you forwarded third one correctly too. If you take the original rule for 40080, the only change from that is that the new one has dst-port=80. Watch the rule's counter, if you make requests from outside and it doesn't increase, it might be your ISP blocking incoming connections. Luckily I've never met such ISP myself, but some don't like home users to run servers.

sindy · Mon Apr 30, 2018 6:37 pm

I have disabled the mikrotik web service. I try to disable hotspot. But all are not working.

My blind shot would be to bind the Mikrotik www service to another port than 80 on top/instead of disabling it if the ISP is not the reason.

Sob · Mon Apr 30, 2018 7:08 pm

But you know it doesn't conflict, dstnat "wins" over local service.

sindy · Mon Apr 30, 2018 8:24 pm

But you know it doesn't conflict, dstnat "wins" over local service.

I've always thought the same but my confidence was shaken recently by some post here. Mabe I've mixed things up and ithe exception was specific to mac-telnet. Anyway, that's why I've called it a blind shot

ZartPARZ · Mon Apr 30, 2018 8:26 pm

If you successfully forwarded two ports, it's likely that you forwarded third one correctly too. If you take the original rule for 40080, the only change from that is that the new one has dst-port=80. Watch the rule's counter, if you make requests from outside and it doesn't increase, it might be your ISP blocking incoming connections. Luckily I've never met such ISP myself, but some don't like home users to run servers.

I tried to change the rule for 40080 to 88, it worked. However, if I change it to 80, the browser cannot connect to my nginx. The rule counter does increase if I try to connect via browser but the nginx log show nothing.

ZartPARZ · Mon Apr 30, 2018 8:27 pm

I have disabled the mikrotik web service. I try to disable hotspot. But all are not working.
My blind shot would be to bind the Mikrotik www service to another port than 80 on top/instead of disabling it if the ISP is not the reason.

I already disable the www service since I only use winbox. Moreover, I already change the www service port to 10080 to be sure, but I still cannot access port 80 from internet.

ZartPARZ · Mon Apr 30, 2018 8:39 pm

It seem like every ports except 80 are working. I am trying to find conflict but nothing found yet. If anyone have an idea please let me know.
Thank you.

bekax5 · Mon Apr 30, 2018 8:43 pm

I have disabled the mikrotik web service. I try to disable hotspot. But all are not working.
My blind shot would be to bind the Mikrotik www service to another port than 80 on top/instead of disabling it if the ISP is not the reason.
I already disable the www service since I only use winbox. Moreover, I already change the www service port to 10080 to be sure, but I still cannot access port 80 from internet.

I'm tempted to ask if you are testing this from inside your LAN ?
This would mean you have to setup Hairpin NAT.

sindy · Mon Apr 30, 2018 9:08 pm

If @Sob is right (and he usually is), then you should be able to find out whether your ISP is blocking traffic to port 80 or not by adding a

chain=prerouting action=passthrough protocol=tcp dst-port=80 dst-address=your.pub.lic.ip

rule to

/ip firewall raw

, attempting to establish a http connection to the public IP of the router from outside, and watching that rule's counter. If it doesn't stay at 0 packets after the attempt, the issue is inside your 'Tik, if it stays at 0, the ISP is guilty.

Sob · Tue May 01, 2018 12:27 am

The rule counter does increase if I try to connect via browser but the nginx log show nothing.

Next step where it can fail is router's firewall filter, forward chain. Is there any rule that can block the connection? If not, it should pass and you should see packets leaving towards server. You should be able to see them using Tools->Torch on router's LAN interface, or you can add logging rule to postrouting. If this happens successfully, then normally it would be server's fault if it didn't work. But it shouldn't happen in this case, when you already forwarded another external port to same internal port and it worked.

ZartPARZ · Tue May 01, 2018 5:30 am

I have disabled the mikrotik web service. I try to disable hotspot. But all are not working.
My blind shot would be to bind the Mikrotik www service to another port than 80 on top/instead of disabling it if the ISP is not the reason.
I already disable the www service since I only use winbox. Moreover, I already change the www service port to 10080 to be sure, but I still cannot access port 80 from internet.
I'm tempted to ask if you are testing this from inside your LAN ?
This would mean you have to setup Hairpin NAT.

No, I test this using LTE on my phone. The Haripin NAT (if I understand correctly, masquerade action on src-nat chain?) on port 80 also not work after I try to set in up. The counter does not go up when I try to connect form LAN with my domain name.

ZartPARZ · Tue May 01, 2018 6:11 am

The rule counter does increase if I try to connect via browser but the nginx log show nothing.
Next step where it can fail is router's firewall filter, forward chain. Is there any rule that can block the connection? If not, it should pass and you should see packets leaving towards server. You should be able to see them using Tools->Torch on router's LAN interface, or you can add logging rule to postrouting. If this happens successfully, then normally it would be server's fault if it didn't work. But it shouldn't happen in this case, when you already forwarded another external port to same internal port and it worked.

In the firewall filter, I have only default rules. I tried to disable them one by one, but port 80 still not accessible.

I tried to use touch tool as you suggest, and I observe some packets. By trying to access port 80 from internet, I can see activity on port 40080 on my server (as src.) in touch. However, in nginx log there is no activity. (The nginx log shows connection log correctly if I access using port 40080)

Thank you.

sindy · Tue May 01, 2018 9:13 am

I'm afraid you'll have to post the output of

export hide-sensitive

after replacing each occurrence of any public IP you do not want to reveal by a distinctive pattern like

my.public.ip.1

And at this stage I would use packet sniffing at both interfaces simultaneously into a file, with filters set to

filter-interface=your-wan-if,your-lan-if filter-ip-protocol=tcp filter-port=80,40080 filter-operator-between-entries=and

to reduce the volume of saved data, and use Wireshark to see what actually happens to the packet as it passes through the 'Tik. Because what you wrote so far suggests that the

dstnat

and

filter

do what you want them to (as not only rule counters show the packets to be coming but also

/tool torch

shows the packet at the output interface with the correctly modified

dst-port

) but possibly something else happens to the packet. Or maybe only the

SYN

packet gets through but not the following ones, because you either filter them directly or they never come from the client because you don't allow the

SYN.ACK

response back to the client, so the nginx gets no application data as the TCP session is not completely established.

ZartPARZ · Wed May 02, 2018 7:51 am

I'm afraid you'll have to post the output of
Code: Select all
export hide-sensitive
after replacing each occurrence of any public IP you do not want to reveal by a distinctive pattern like
Code: Select all
my.public.ip.1
And at this stage I would use packet sniffing at both interfaces simultaneously into a file, with filters set to
Code: Select all
filter-interface=your-wan-if,your-lan-if filter-ip-protocol=tcp filter-port=80,40080 filter-operator-between-entries=and
to reduce the volume of saved data, and use Wireshark to see what actually happens to the packet as it passes through the 'Tik. Because what you wrote so far suggests that the
Code: Select all
dstnat
and
Code: Select all
filter
do what you want them to (as not only rule counters show the packets to be coming but also
Code: Select all
/tool torch
shows the packet at the output interface with the correctly modified
Code: Select all
dst-port
) but possibly something else happens to the packet. Or maybe only the
Code: Select all
SYN
packet gets through but not the following ones, because you either filter them directly or they never come from the client because you don't allow the
Code: Select all
SYN.ACK
response back to the client, so the nginx gets no application data as the TCP session is not completely established.

Hi,

Below is my config from export command. I have marked some mac, dhcp static, hotspot bining and my script.
And about packet sniffing, I afraid I do not have enough skill for that, I may need some time for learning, sorry.

# may/02/2018 11:20:35 by RouterOS 6.42.1
# software id = M17Z-QURP
#
# model = RouterBOARD 3011UiAS
# serial number = ***
/interface bridge
add admin-mac=*** auto-mac=no comment=defconf fast-forward=no \
    name=bridge priority=0x9000
/interface ethernet
set [ find default-name=ether1 ] mac-address=***
set [ find default-name=ether2 ] name=ether2-master
set [ find default-name=ether6 ] name=ether6-master
set [ find default-name=sfp1 ] auto-negotiation=no l2mtu=1598 mac-address=\
    *** rx-flow-control=on tx-flow-control=on
/interface pppoe-client
add add-default-route=yes default-route-distance=0 disabled=no interface=ether1 \
    keepalive-timeout=disabled max-mru=1492 max-mtu=1492 name=\
    pppoe-3bbfttx-ether1 user=***
/interface vlan
add disabled=yes interface=sfp1 name=vlan_33_sfp vlan-id=33
/interface pppoe-client
add add-default-route=yes default-route-distance=0 interface=vlan_33_sfp \
    keepalive-timeout=disabled max-mru=1492 max-mtu=1492 name=pppoe-3bbfttx-sfp \
    user=***
/interface list
add exclude=dynamic name=discover
add name=mactel
add name=mac-winbox
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip hotspot profile
add hotspot-address=192.168.88.100 html-directory="" login-by=\
    http-chap,http-pap name=hotspot1 use-radius=yes
/ip hotspot
add disabled=no idle-timeout=none interface=bridge name=hotspot_server profile=\
    hotspot1
/ip pool
add name=dhcp ranges=10.200.0.11-10.255.255.254
add name=ippool1 ranges=10.215.0.1-10.215.0.254
/ip dhcp-server
add address-pool=ippool1 authoritative=after-2sec-delay interface=bridge name=\
    defconf
add address-pool=ippool1 authoritative=after-2sec-delay disabled=no interface=\
    bridge lease-time=3h name=dhcp1 use-radius=yes
/snmp community
set [ find default=yes ] addresses=0.0.0.0/0
/system logging action
set 1 disk-file-count=1000
/interface bridge port
add bridge=bridge comment=defconf interface=ether2-master
add bridge=bridge comment=defconf interface=ether6-master
add bridge=bridge comment=defconf hw=no interface=sfp1
add bridge=bridge disabled=yes interface=ether1
add bridge=bridge interface=ether3
add bridge=bridge interface=ether4
add bridge=bridge interface=ether5
add bridge=bridge interface=ether7
add bridge=bridge interface=ether8
add bridge=bridge interface=ether9
add bridge=bridge interface=ether10
/ip neighbor discovery-settings
set discover-interface-list=none
/interface list member
add interface=ether2-master list=discover
add interface=ether3 list=discover
add interface=ether4 list=discover
add interface=ether5 list=discover
add interface=sfp1 list=discover
add interface=ether6-master list=discover
add interface=ether7 list=discover
add interface=ether8 list=discover
add interface=ether9 list=discover
add interface=ether10 list=discover
add interface=bridge list=discover
add interface=pppoe-3bbfttx-ether1 list=discover
add interface=vlan_33_sfp list=discover
add interface=pppoe-3bbfttx-sfp list=discover
add interface=ether2-master list=mactel
add interface=ether6-master list=mactel
add interface=ether2-master list=mac-winbox
add interface=sfp1 list=mactel
add interface=ether6-master list=mac-winbox
add interface=sfp1 list=mac-winbox
/ip address
add address=my.mikrotik.ip/10 comment=defconf interface=bridge network=10.192.0.0
/ip cloud
set ddns-enabled=yes update-time=no
/ip dhcp-client
add comment=defconf dhcp-options=hostname,clientid disabled=no interface=ether1

/ip dhcp-server network
add address=10.192.0.0/10 comment=defconf dns-server=1.1.1.1,8.8.8.8,8.8.4.4 \
    gateway=my.mikrotik.ip
/ip dns
set allow-remote-requests=yes servers=1.1.1.1,8.8.8.8
/ip dns static
add address=my.mikrotik.ip name=router
add address=my.home.server name=mainserver.local
/ip firewall filter
add action=passthrough chain=unused-hs-chain comment="place hotspot rules here" \
    disabled=yes
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
    connection-state=established,related
add action=accept chain=forward comment="defconf: accept established,related" \
    connection-state=established,related
add action=drop chain=forward comment="defconf: drop invalid" connection-state=\
    invalid
add action=drop chain=forward comment=\
    "defconf:  drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
    connection-state=new in-interface=ether1
add action=accept chain=input protocol=icmp
add action=accept chain=input connection-state=established
add action=accept chain=input connection-state=related
add action=drop chain=input in-interface=pppoe-3bbfttx-ether1
/ip firewall nat
add action=passthrough chain=unused-hs-chain comment="place hotspot rules here" \
    disabled=yes
# no interface
add action=masquerade chain=srcnat comment="defconf: masquerade" out-interface=\
    *F
add action=masquerade chain=srcnat out-interface=pppoe-3bbfttx-ether1
add action=dst-nat chain=dstnat dst-port=80 in-interface=pppoe-3bbfttx-ether1 \
    log=yes log-prefix=TEST protocol=tcp to-addresses=my.home.server to-ports=40080
add action=dst-nat chain=dstnat dst-port=20080 protocol=tcp to-addresses=\
    my.home.server to-ports=80
add action=dst-nat chain=dstnat disabled=yes dst-port=11111 log=yes protocol=\
    tcp to-addresses=my.home.server to-ports=11111
add action=dst-nat chain=dstnat dst-port=55557 protocol=tcp to-addresses=\
    my.home.server to-ports=55557
add action=dst-nat chain=dstnat dst-port=55557 protocol=udp to-addresses=\
    my.home.server to-ports=55557
add action=dst-nat chain=dstnat dst-port=8008 protocol=tcp to-addresses=\
    my.home.server to-ports=8008
add action=dst-nat chain=dstnat dst-port=8009 protocol=tcp to-addresses=\
    my.home.server to-ports=8009
add action=dst-nat chain=dstnat dst-port=9091 protocol=tcp to-addresses=\
    my.home.server to-ports=9091
add action=dst-nat chain=dstnat dst-port=*** log=yes protocol=tcp \
    to-addresses=my.home.server to-ports=22
add action=dst-nat chain=dstnat dst-port=8443 protocol=tcp to-addresses=\
    my.home.server to-ports=8443
add action=dst-nat chain=dstnat dst-port=5201 protocol=tcp to-addresses=\
    my.home.server to-ports=5201
add action=dst-nat chain=dstnat dst-port=40080 log-prefix=TEST2 protocol=tcp \
    to-addresses=my.home.server to-ports=40080
add action=masquerade chain=srcnat dst-address=my.home.server dst-port=8008 \
    protocol=tcp src-address=10.0.0.0/8
add action=masquerade chain=srcnat dst-address=my.onu.modem out-interface=ether1 \
    src-address=10.192.0.0/10
add action=masquerade chain=srcnat dst-address=my.home.server dst-port=5201 \
    protocol=tcp src-address=10.0.0.0/8
add action=masquerade chain=srcnat dst-address=my.home.server dst-port=8443 \
    protocol=tcp src-address=10.0.0.0/8
add action=dst-nat chain=dstnat dst-port=8000 protocol=tcp to-addresses=\
    a.device to-ports=8000
add action=masquerade chain=srcnat dst-address=a.device dst-port=8000 \
    protocol=tcp src-address=10.0.0.0/8
add action=dst-nat chain=dstnat dst-port=11940 protocol=tcp to-addresses=\
    my.home.server to-ports=11940
add action=masquerade chain=srcnat disabled=yes dst-address=my.home.server \
    dst-port=80 protocol=tcp src-address=10.192.0.0/10 to-ports=80
/ip hotspot ip-binding
***
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes port=10080
set ssh disabled=yes
set www-ssl port=10443
set api disabled=yes
set winbox address=10.192.0.0/10
set api-ssl disabled=yes
/ip upnp
set allow-disable-external-interface=yes enabled=yes
/ip upnp interfaces
add interface=ether2-master type=internal
add interface=ether6-master type=internal
/lcd
set time-interval=hour
/lcd pin
set pin-number=1379
/radius
add address=my.home.server service=ppp,hotspot,wireless,dhcp
/system clock
set time-zone-name=Asia/Bangkok
/system identity
set name=main-router
/system logging
set 0 action=disk
set 1 action=disk
set 2 action=disk
add action=disk topics=critical
add action=disk disabled=yes topics=dhcp
add action=disk topics=hotspot
add action=disk topics=radius
add action=disk disabled=yes topics=pppoe
add action=disk topics=script
add action=disk topics=firewall
/system ntp client
set enabled=yes primary-ntp=*** server-dns-names=***
/system routerboard settings
set silent-boot=no
/system scheduler
add interval=10m name=noip-updater on-event=noip-nat policy=\
    read,write,policy,test,password,sensitive start-date=dec/28/2016 \
    start-time=12:38:40
/system script
***
/tool mac-server
set allowed-interface-list=none
/tool mac-server mac-winbox
set allowed-interface-list=mac-winbox
/tool mac-server ping
set enabled=no
/tool traffic-monitor
add disabled=yes interface=ether1 name=tmon1 threshold=0 traffic=receive

ZartPARZ · Wed May 02, 2018 8:13 am

I want to add the NAT rule log for more information. These logs are shown when I try to connect to port 80 using my phone.

TEST dsnnat: in :pppoe-3bbfttx-ether1 out:(unknow 0), proto TCP (SYN), my.lte.ip:xxx->my.public.ip:80, len 60

CZFan · Wed May 02, 2018 1:07 pm

That indicates ISP not blocking port 80.

Change the following rule:

add action=drop chain=forward comment=\
"defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
connection-state=new in-interface=ether1 to pppoe-3bbfttx-ether1

sindy · Wed May 02, 2018 1:32 pm

Below is my config from export command.

One thing which is probably unrelated to the topics but should be fixed as I have no idea what it may do is the rule in

/ip firewall nat

add action=masquerade chain=srcnat comment="defconf: masquerade" out-interface=*F

It refers to an

out-interface

which you have removed from the system so it doesn't work. If that was a dynamic interface, its dynamic re-creation will not rebind the rule to that interface.

Also, as @CZFan has just pointed out, the "drop anything not dst-nat'ed" rule is currently useless as it refers to a wrong interface (from the point of view of the firewall, the pppoe interface is the

in-interface

, the fact that the pppoe protocol runs over

ether1

is not relevant for the firewall), but that is a hint towards improving security, not towards solving the issue.

I cannot see anything in your static (manually configured) firewall rules which could explain what is going regarding your redirection.

However, I can see you have hotspot and upnp functionality enabled, so please post also the output of

/ip firewall nat print

,

/ip firewall filter print

,

/ip firewall mangle print

(after substituting sensitive information of course) as these show also the rules dynamically created by RouterOS itself and the upnp clients.

I want to add the NAT rule log for more information. These logs are shown when I try to connect to port 80 using my phone.
Code: Select all
TEST dsnnat: in :pppoe-3bbfttx-ether1 out:(unknow 0), proto TCP (SYN), my.lte.ip:xxx->my.public.ip:80, len 60

What may not be obvious at first glance is that the

nat

rule table is only consulted for the initial packet of each condition. So the fact that only one packet (the

SYN

one) is logged at this exact place doesn't explain anything because it is what should happen (you can verify this by adding

log=yes

to some other

dst-nat

rule).

To speed the analysis up, before posting the firewall print outputs as requested above, please add another two rules:

/ip firewall mangle
add chain=postrouting action=log protocol=tcp dst-address=internal.ip.of.the.server dst-port=40080 log-prefix="to server: "
add chain=prerouting action=log protocol=tcp src-address=internal.ip.of.the.server src-port=40080 log-prefix="from server: "

Place these rules as high as the system allows you in the

mangle

table (a rule cannot be placed above dynamically created rules and I don't know how many dynamic rules are there in your case) and try to connect from the phone to the server one more time.

The first rule should log the same

SYN

packet like the

dst-nat

rule does but also any further one from the client to the server as close to the output interface as possible (so if the packet is logged there, it has passed successfully through routing and is just about to be sent out), the second one logs the response packets from the server soon as they come in. So if the second rule logs a packet, you know that the server has responded (and in our case, the response got lost on the way back to the client).

ZartPARZ · Wed May 02, 2018 3:50 pm

Hi Sindy, I have try as you suggested. The results are below.

This is if I connect to port 80 with my phone.

18:32:20 firewall,info dst-nat rule 40080:  dstnat: in:pppoe-3bbfttx-ether1 out:(unknown 0), proto TCP (SYN), my.lte.ip:46964->mikrotik.public.ip:40080, len 60 
18:32:20 firewall,info to server:  postrouting: in:(unknown 0) out:bridge, proto TCP (SYN), my.lte.ip:46964->my.home.server:40080, NAT my.lte.ip:46964->(mikrotik.public.ip:40080->my.home.server:40080), len 60 
18:32:20 firewall,info from server:  prerouting: in:bridge out:(unknown 0), src-mac ***, proto TCP (SYN,ACK), my.home.server:40080->my.lte.ip:46964, NAT (my.home.server:40080->mikrotik.public.ip:40080)->my.lte.ip:46964, len 60 
18:32:20 firewall,info to server:  postrouting: in:(unknown 0) out:bridge, src-mac ***, proto TCP (ACK), my.lte.ip:46964->my.home.server:40080, NAT my.lte.ip:46964->(mikrotik.public.ip:40080->my.home.server:40080), len 52 
18:33:25 firewall,info from server:  prerouting: in:bridge out:(unknown 0), src-mac ***, proto TCP (ACK,FIN), my.home.server:40080->my.lte.ip:46964, NAT (my.home.server:40080->mikrotik.public.ip:40080)->my.lte.ip:46964, len 52 
18:33:25 firewall,info to server:  postrouting: in:(unknown 0) out:bridge, src-mac ***, proto TCP (ACK,FIN), my.lte.ip:46964->my.home.server:40080, NAT my.lte.ip:46964->(mikrotik.public.ip:40080->my.home.server:40080), len 52 
18:33:25 firewall,info from server:  prerouting: in:bridge out:(unknown 0), src-mac ***, proto TCP (ACK), my.home.server:40080->my.lte.ip:46964, NAT (my.home.server:40080->mikrotik.public.ip:40080)->my.lte.ip:46964, len 52

This is when I connect to port 40080 with my phone.

18:36:44 firewall,info "dst-nat rule 80: " dstnat: in:pppoe-3bbfttx-ether1 out:(unknown 0), proto TCP (SYN), my.lte.ip3:36185->mikrotik.public.ip:80, len 60 
18:36:44 firewall,info to server:  postrouting: in:(unknown 0) out:bridge, proto TCP (SYN), my.lte.ip3:36185->my.home.server:40080, NAT my.lte.ip:36185->(mikrotik.public.ip:80->my.home.server:40080), len 60 
18:36:44 firewall,info from server:  prerouting: in:bridge out:(unknown 0), src-mac ***, proto TCP (SYN,ACK), my.home.server:40080->my.lte.ip3:36185, NAT (my.home.server:40080->mikrotik.public.ip:80)->my.lte.ip:36185, len 60 
18:36:45 firewall,info from server:  prerouting: in:bridge out:(unknown 0), src-mac ***, proto TCP (SYN,ACK), my.home.server:40080->my.lte.ip3:36185, NAT (my.home.server:40080->mikrotik.public.ip:80)->my.lte.ip:36185, len 60 
18:36:45 firewall,info to server:  postrouting: in:(unknown 0) out:bridge, proto TCP (SYN), my.lte.ip3:36185->my.home.server:40080, NAT my.lte.ip3:36185->(mikrotik.public.ip:80->my.home.server:40080), len 60 
18:36:45 firewall,info from server:  prerouting: in:bridge out:(unknown 0), src-mac ***, proto TCP (SYN,ACK), my.home.server:40080->my.lte.ip3:36185, NAT (my.home.server:40080->mikrotik.public.ip:80)->my.lte.ip:36185, len 60 
18:36:47 firewall,info from server:  prerouting: in:bridge out:(unknown 0), src-mac ***, proto TCP (SYN,ACK), my.home.server:40080->my.lte.ip3:36185, NAT (my.home.server:40080->mikrotik.public.ip:80)->my.lte.ip:36185, len 60 
18:36:47 firewall,info to server:  postrouting: in:(unknown 0) out:bridge, proto TCP (SYN), my.lte.ip3:36185->my.home.server:40080, NAT my.lte.ip:36185->(mikrotik.public.ip:80->my.home.server:40080), len 60 
18:36:47 firewall,info from server:  prerouting: in:bridge out:(unknown 0), src-mac ***, proto TCP (SYN,ACK), my.home.server:40080->my.lte.ip3:36185, NAT (my.home.server:40080->mikrotik.public.ip:80)->my.lte.ip:36185, len 60

/ip firewall nat print

 0  D chain=dstnat action=jump jump-target=hotspot hotspot=from-client 

 1  D chain=hotspot action=jump jump-target=pre-hotspot 

 2  D chain=hotspot action=redirect to-ports=64872 protocol=udp dst-port=53 

 3  D chain=hotspot action=redirect to-ports=64872 protocol=tcp dst-port=53 

 4  D chain=hotspot action=redirect to-ports=64873 protocol=tcp hotspot=local-dst dst-port=80 

 5  D chain=hotspot action=redirect to-ports=64875 protocol=tcp hotspot=local-dst dst-port=443 

 6  D chain=hotspot action=jump jump-target=hs-unauth protocol=tcp hotspot=!auth 

 7  D chain=hotspot action=jump jump-target=hs-auth protocol=tcp hotspot=auth 

 8  D chain=hs-unauth action=redirect to-ports=64874 protocol=tcp dst-port=80 

 9  D chain=hs-unauth action=redirect to-ports=64874 protocol=tcp dst-port=3128 

10  D chain=hs-unauth action=redirect to-ports=64874 protocol=tcp dst-port=8080 

11  D chain=hs-unauth action=redirect to-ports=64875 protocol=tcp dst-port=443 

12  D chain=hs-unauth action=jump jump-target=hs-smtp protocol=tcp dst-port=25 

13  D chain=hs-auth action=redirect to-ports=64874 protocol=tcp hotspot=http 

14  D chain=hs-auth action=jump jump-target=hs-smtp protocol=tcp dst-port=25 

15 X  ;;; place hotspot rules here
      chain=unused-hs-chain action=passthrough 

16    chain=srcnat action=masquerade out-interface=pppoe-3bbfttx-ether1 log=no log-prefix="" 

17    chain=dstnat action=dst-nat to-addresses=my.home.server to-ports=40080 protocol=tcp in-interface=pppoe-3bbfttx-ether1 dst-port=80 log=yes 
      log-prefix=""dst-nat rule 80: "" 

18    chain=dstnat action=dst-nat to-addresses=my.home.server to-ports=80 protocol=tcp dst-port=20080 log=no log-prefix="" 

19 X  chain=dstnat action=dst-nat to-addresses=my.home.server to-ports=11111 protocol=tcp dst-port=11111 log=yes log-prefix="" 

20    chain=dstnat action=dst-nat to-addresses=my.home.server to-ports=55557 protocol=tcp dst-port=55557 log=no log-prefix="" 

21    chain=dstnat action=dst-nat to-addresses=my.home.server to-ports=55557 protocol=udp dst-port=55557 log=no log-prefix="" 

22    chain=dstnat action=dst-nat to-addresses=my.home.server to-ports=8008 protocol=tcp dst-port=8008 log=no log-prefix="" 

23    chain=dstnat action=dst-nat to-addresses=my.home.server to-ports=8009 protocol=tcp dst-port=8009 log=no log-prefix="" 

24    chain=dstnat action=dst-nat to-addresses=my.home.server to-ports=9091 protocol=tcp dst-port=9091 log=no log-prefix="" 

25    chain=dstnat action=dst-nat to-addresses=my.home.server to-ports=22 protocol=tcp src-address-list=!blacklist dst-port=22000 log=yes log-prefix="server-ssh:" 

26    chain=dstnat action=dst-nat to-addresses=my.home.server to-ports=8443 protocol=tcp dst-port=8443 log=no log-prefix="" 

27    chain=dstnat action=dst-nat to-addresses=my.home.server to-ports=5201 protocol=tcp dst-port=5201 log=no log-prefix="" 

28    chain=dstnat action=dst-nat to-addresses=my.home.server to-ports=40080 protocol=tcp dst-port=40080 log=yes log-prefix="dst-nat rule 40080: " 

29    chain=srcnat action=masquerade protocol=tcp src-address=10.0.0.0/8 dst-address=my.home.server dst-port=8008 log=no log-prefix="" 

30    chain=srcnat action=masquerade src-address=10.192.0.0/10 dst-address=my.onu.ip out-interface=ether1 log=no log-prefix="" 

31    chain=srcnat action=masquerade protocol=tcp src-address=10.0.0.0/8 dst-address=my.home.server dst-port=5201 log=no log-prefix="" 

32    chain=srcnat action=masquerade protocol=tcp src-address=10.0.0.0/8 dst-address=my.home.server dst-port=8443 log=no log-prefix="" 

33    chain=dstnat action=dst-nat to-addresses=my.device to-ports=8000 protocol=tcp dst-port=8000 log=no log-prefix="" 

34    chain=srcnat action=masquerade protocol=tcp src-address=10.0.0.0/8 dst-address=my.device dst-port=8000 log=no log-prefix="" 

35    chain=dstnat action=dst-nat to-addresses=my.home.server to-ports=11940 protocol=tcp dst-port=11940 log=yes log-prefix="server-pvpn: " 

36 X  chain=srcnat action=masquerade to-ports=80 protocol=tcp src-address=10.192.0.0/10 dst-address=my.home.server dst-port=80 log=no log-prefix=""

/ip firewall filter print

0  D ;;; special dummy rule to show fasttrack counters
      chain=forward action=passthrough 

 1  D chain=forward action=jump jump-target=hs-unauth hotspot=from-client,!auth 

 2  D chain=forward action=jump jump-target=hs-unauth-to hotspot=to-client,!auth 

 3  D chain=input action=jump jump-target=hs-input hotspot=from-client 

 4  D chain=input action=drop protocol=tcp hotspot=!from-client dst-port=64872-64875 

 5  D chain=hs-input action=jump jump-target=pre-hs-input 

 6  D chain=hs-input action=accept protocol=udp dst-port=64872 

 7  D chain=hs-input action=accept protocol=tcp dst-port=64872-64875 

 8  D chain=hs-input action=jump jump-target=hs-unauth hotspot=!auth 

 9  D chain=hs-unauth action=reject reject-with=tcp-reset protocol=tcp 

10  D chain=hs-unauth action=reject reject-with=icmp-net-prohibited 

11  D chain=hs-unauth-to action=reject reject-with=icmp-host-prohibited 

12 X  ;;; place hotspot rules here
      chain=unused-hs-chain action=passthrough 

13    ;;; defconf: fasttrack
      chain=forward action=fasttrack-connection connection-state=established,related log=no log-prefix="" 

14    ;;; defconf: accept established,related
      chain=forward action=accept connection-state=established,related log=no log-prefix="" 

15    ;;; defconf: drop invalid
      chain=forward action=drop connection-state=invalid log=no log-prefix="" 

16    chain=input action=drop src-address-list=blacklist log=yes log-prefix="Firewall input blacklist:" 

17    ;;; defconf:  drop all from WAN not DSTNATed
      chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface=pppoe-3bbfttx-ether1 log=no log-prefix="" 

18    chain=input action=accept protocol=icmp 

19    chain=input action=accept connection-state=established 

20    chain=input action=accept connection-state=related 

21    chain=input action=drop in-interface=pppoe-3bbfttx-ether1

/ip firewall mangle print

 0  D ;;; special dummy rule to show fasttrack counters
      chain=prerouting action=passthrough 

 1  D ;;; special dummy rule to show fasttrack counters
      chain=forward action=passthrough 

 2  D ;;; special dummy rule to show fasttrack counters
      chain=postrouting action=passthrough 

 3    chain=postrouting action=log protocol=tcp dst-address=my.home.server dst-port=40080 log-prefix="to server: " 

 4    chain=prerouting action=log protocol=tcp src-address=my.home.server src-port=40080 log-prefix="from server: "

sindy · Wed May 02, 2018 5:15 pm

In the Mikrotik log you can see retransmissions of the

SYN

packet from the client to the server and retransmissions of the

SYN,ACK

packet from the server to the client. This reveals that the server responds but the response never reaches the client.

The consequence is that the TCP session never establishes, which explains why there is nothing in the nginx application log - nginx has never received any actual data because the TCP stack only delivers the session payload to the application, and here no payload could be transmitted.

The dynamically added firewall rules don't reveal anything at first glance, but they must be the reason. As I haven't spotted any rules created by upnp, I suspect one of the hotspot rules to interfere in some way as the hotspot interface is

bridge

which is the same one to which the server is connected.

Are you able to disable the hotspot functionality for a while and try again so that we could confirm or deny this suspicion before digging further?

Once you disable the hotspot, the related dynamic rules (those with

in the leftmost column) should disappear from the output of

print

.

If that helps, re-enabling the hotspot and watching the counters of the dynamically added hotspot rules while attempting to connect should help find the conflicting rule, but placing the server outside the hotspot bridge could be an easier solution.

ZartPARZ · Wed May 02, 2018 6:00 pm

In the Mikrotik log you can see retransmissions of the
Code: Select all
SYN
packet from the client to the server and retransmissions of the
Code: Select all
SYN,ACK
packet from the server to the client. This reveals that the server responds but the response never reaches the client.

The consequence is that the TCP session never establishes, which explains why there is nothing in the nginx application log - nginx has never received any actual data because the TCP stack only delivers the session payload to the application, and here no payload could be transmitted.

The dynamically added firewall rules don't reveal anything at first glance, but they must be the reason. As I haven't spotted any rules created by upnp, I suspect one of the hotspot rules to interfere in some way as the hotspot interface is
Code: Select all
bridge
which is the same one to which the server is connected.

Are you able to disable the hotspot functionality for a while and try again so that we could confirm or deny this suspicion before digging further?

Once you disable the hotspot, the related dynamic rules (those with
Code: Select all
D
in the leftmost column) should disappear from the output of
Code: Select all
print
.

If that helps, re-enabling the hotspot and watching the counters of the dynamically added hotspot rules while attempting to connect should help find the conflicting rule, but placing the server outside the hotspot bridge could be an easier solution.

I have already try disable the hotspot, but unfortunately it does not solve the problem. And the server is already on hotspot's bypass list (I don't know if it relate to the problem or not).

Regards.

sindy · Wed May 02, 2018 6:36 pm

the server is already on hotspot's bypass list (I don't know if it relate to the problem or not).

Are you talking about this?
If so, which variant (regular/bypassed/blocked) have you set for the server? None seems safe to me, unfortunately I have no experience with hotspot. Yet it is not clear to me why that should affect that single redirection selectively, so it is probably not the reason.
When you disable the hotspot, do all the dynamic rules disappear from the firewall tables?

Also, the log you've posted before shows that the connection tracker knows about the unsuccessful attempt, can you try once more and while it keeps trying, do

/ip firewall connection print detail where reply-src-address~":40080"

and post the result after obfuscating the IPs?

ZartPARZ · Wed May 02, 2018 7:48 pm

the server is already on hotspot's bypass list (I don't know if it relate to the problem or not).
Are you talking about this?
If so, which variant (regular/bypassed/blocked) have you set for the server? None seems safe to me, unfortunately I have no experience with hotspot. Yet it is not clear to me why that should affect that single redirection selectively, so it is probably not the reason.
When you disable the hotspot, do all the dynamic rules disappear from the firewall tables?

Also, the log you've posted before shows that the connection tracker knows about the unsuccessful attempt, can you try once more and while it keeps trying, do
Code: Select all
/ip firewall connection print detail where reply-src-address~":40080"
and post the result after obfuscating the IPs?

Yes, I set bypassed for my server.
When I disable the hotspot, all dynamic NAT rules are gone. Moreover, all filter rule exept rule #0 are also gone.

And this is what I got from your suggested command.

0  S C F d protocol=tcp src-address=my.lte.ip:40444 dst-address=mikrotik.public.ip:80 reply-src-address=my.home.server:40080 reply-dst-address=my.lte.ip:40444 
            tcp-state=syn-recv timeout=2s orig-packets=1 orig-bytes=60 orig-fasttrack-packets=0 orig-fasttrack-bytes=0 repl-packets=1 repl-bytes=60 
            repl-fasttrack-packets=0 repl-fasttrack-bytes=0 orig-rate=0bps repl-rate=0bps

sindy · Wed May 02, 2018 9:23 pm

And this is what I got from your suggested command.

0  S C F d protocol=tcp src-address=my.lte.ip:40444 dst-address=mikrotik.public.ip:80 reply-src-address=my.home.server:40080 reply-dst-address=my.lte.ip:40444 
            tcp-state=syn-recv timeout=2s orig-packets=1 orig-bytes=60 orig-fasttrack-packets=0 orig-fasttrack-bytes=0 repl-packets=1 repl-bytes=60 
            repl-fasttrack-packets=0 repl-fasttrack-bytes=0 orig-rate=0bps repl-rate=0bps

OK, so please add one more rule right below the two ones I've given before, try again to connect to both 80 and 40080 and post the logs. I'd like to be sure that the issue is inside the 'Tik without forcing you to sniff packets:

/ip firewall mangle
add chain=postrouting action=log protocol=tcp dst-address=internal.ip.of.the.server dst-port=40080 log-prefix="to server: "
add chain=prerouting action=log protocol=tcp src-address=internal.ip.of.the.server src-port=40080 log-prefix="from server: "
add chain=postrouting action=log protocol=tcp src-port=80,40080 log-prefix="back to client: "

ZartPARZ · Thu May 03, 2018 2:45 am

And this is what I got from your suggested command.

0  S C F d protocol=tcp src-address=my.lte.ip:40444 dst-address=mikrotik.public.ip:80 reply-src-address=my.home.server:40080 reply-dst-address=my.lte.ip:40444 
            tcp-state=syn-recv timeout=2s orig-packets=1 orig-bytes=60 orig-fasttrack-packets=0 orig-fasttrack-bytes=0 repl-packets=1 repl-bytes=60 
            repl-fasttrack-packets=0 repl-fasttrack-bytes=0 orig-rate=0bps repl-rate=0bps

OK, so please add one more rule right below the two ones I've given before, try again to connect to both 80 and 40080 and post the logs. I'd like to be sure that the issue is inside the 'Tik without forcing you to sniff packets:

/ip firewall mangle
add chain=postrouting action=log protocol=tcp dst-address=internal.ip.of.the.server dst-port=40080 log-prefix="to server: "
add chain=prerouting action=log protocol=tcp src-address=internal.ip.of.the.server src-port=40080 log-prefix="from server: "
add chain=postrouting action=log protocol=tcp src-port=80,40080 log-prefix="back to client: "

Below is the output of the last rule. The output is exactly the same if I connect to port 40080 from internet.

may/03 06:32:46 firewall,info back to client:  postrouting: in:(unknown 0) out:pppoe-3bbfttx-ether1, src-mac ***, proto TCP (SYN,ACK), my.home.server:40080->my.lte.ip:43102, NAT (my.home.server:40080->mikrotik.public.ip:80)->my.lte.ip:43102, len 60

sindy · Thu May 03, 2018 11:41 am

Okay. In the

postrouting

chain,

mangle

is placed right before

nat

, so I suppose the "un-nat" reversing the

dst-nat

for server->client responses works as well, but to be bullet-proof, this is your turbo-introduction to packet sniffing:

/tool sniffer set filter-interface=pppoe-3bbfttx-ether1 filter-ip-protocol=tcp filter-operator-between-entries=and filter-port=80,40080
/tool sniffer start

make the usual attempt to connect to
Code: Select all
```
your.pub.lic.ip:80
```
(do not try 40080, the sniffing buffer in the memory is a rollover one).

continue by

/tool sniffer stop
/tool sniffer packet print detail

post the output here (replacing the IP adresses and MAC addresses as usually, but using text editor's "find and replace" function so that you could see immediately if e.g. a source MAC address in client->server direction would differ from destination MAC address in server->client direction).

ZartPARZ · Thu May 03, 2018 8:02 pm

Hi, below is the output of the sniffer tool as you suggest. There are two unknown ip address here. The unknown.ip.1 is probably one of my fttx isp's server. And unknown.ip.2 is probably my lte carier's server.

 0 time=3.395 num=1 direction=rx interface=pppoe-3bbfttx-ether1 src-address=my.lte.ip:44811 dst-address=mikrotik.public.ip:80 (http) protocol=ip ip-protocol=tcp 
   size=60 cpu=0 fp=no ip-packet-size=60 ip-header-size=20 dscp=0 identification=54429 fragment-offset=0 ttl=45 tcp-flags=syn 

 1 time=3.395 num=2 direction=tx interface=pppoe-3bbfttx-ether1 src-address=mikrotik.public.ip:80 (http) dst-address=my.lte.ip:44811 protocol=ip ip-protocol=tcp 
   size=60 cpu=1 fp=no ip-packet-size=60 ip-header-size=20 dscp=0 identification=0 fragment-offset=0 ttl=63 tcp-flags=syn,ack 

 2 time=3.479 num=3 direction=tx interface=pppoe-3bbfttx-ether1 src-address=mikrotik.public.ip:56999 dst-address=unknown.ip.1:80 (http) protocol=ip ip-protocol=tcp 
   size=40 cpu=1 fp=no ip-packet-size=40 ip-header-size=20 dscp=0 identification=7790 fragment-offset=0 ttl=127 tcp-flags=fin,ack 

 3 time=3.484 num=4 direction=rx interface=pppoe-3bbfttx-ether1 src-address=unknown.ip.1:80 (http) dst-address=mikrotik.public.ip:56999 protocol=ip ip-protocol=tcp 
   size=40 cpu=0 fp=no ip-packet-size=40 ip-header-size=20 dscp=0 identification=60505 fragment-offset=0 ttl=60 tcp-flags=fin,ack 

 4 time=3.484 num=5 direction=tx interface=pppoe-3bbfttx-ether1 src-address=mikrotik.public.ip:56999 dst-address=unknown.ip.1:80 (http) protocol=ip ip-protocol=tcp 
   size=40 cpu=1 fp=no ip-packet-size=40 ip-header-size=20 dscp=0 identification=7791 fragment-offset=0 ttl=127 tcp-flags=ack 

 5 time=4.392 num=6 direction=tx interface=pppoe-3bbfttx-ether1 src-address=mikrotik.public.ip:80 (http) dst-address=my.lte.ip:44811 protocol=ip ip-protocol=tcp 
   size=60 cpu=1 fp=no ip-packet-size=60 ip-header-size=20 dscp=0 identification=0 fragment-offset=0 ttl=63 tcp-flags=syn,ack 

 6 time=4.394 num=7 direction=rx interface=pppoe-3bbfttx-ether1 src-address=my.lte.ip:44811 dst-address=mikrotik.public.ip:80 (http) protocol=ip ip-protocol=tcp 
   size=60 cpu=0 fp=no ip-packet-size=60 ip-header-size=20 dscp=0 identification=54979 fragment-offset=0 ttl=45 tcp-flags=syn 

 7 time=4.395 num=8 direction=tx interface=pppoe-3bbfttx-ether1 src-address=mikrotik.public.ip:80 (http) dst-address=my.lte.ip:44811 protocol=ip ip-protocol=tcp 
   size=60 cpu=1 fp=no ip-packet-size=60 ip-header-size=20 dscp=0 identification=0 fragment-offset=0 ttl=63 tcp-flags=syn,ack 

 8 time=6.392 num=9 direction=tx interface=pppoe-3bbfttx-ether1 src-address=mikrotik.public.ip:80 (http) dst-address=my.lte.ip:44811 protocol=ip ip-protocol=tcp 
   size=60 cpu=1 fp=no ip-packet-size=60 ip-header-size=20 dscp=0 identification=0 fragment-offset=0 ttl=63 tcp-flags=syn,ack 

 9 time=6.394 num=10 direction=rx interface=pppoe-3bbfttx-ether1 src-address=my.lte.ip:44811 dst-address=mikrotik.public.ip:80 (http) protocol=ip ip-protocol=tc>
   size=60 cpu=0 fp=no ip-packet-size=60 ip-header-size=20 dscp=0 identification=55902 fragment-offset=0 ttl=45 tcp-flags=syn 

10 time=6.395 num=11 direction=tx interface=pppoe-3bbfttx-ether1 src-address=mikrotik.public.ip:80 (http) dst-address=my.lte.ip:44811 protocol=ip ip-protocol=tc>
   size=60 cpu=1 fp=no ip-packet-size=60 ip-header-size=20 dscp=0 identification=0 fragment-offset=0 ttl=63 tcp-flags=syn,ack 

11 time=8.508 num=12 direction=rx interface=pppoe-3bbfttx-ether1 src-address=unknown.ip.2:7745 dst-address=mikrotik.public.ip:80 (http) protocol=ip ip-protocol=tcp 
   size=52 cpu=0 fp=no ip-packet-size=52 ip-header-size=20 dscp=0 identification=5178 fragment-offset=0 ttl=243 tcp-flags=syn 

12 time=8.508 num=13 direction=tx interface=pppoe-3bbfttx-ether1 src-address=mikrotik.public.ip:80 (http) dst-address=unknown.ip.2:7745 protocol=ip ip-protocol=tcp 
   size=52 cpu=1 fp=no ip-packet-size=52 ip-header-size=20 dscp=0 identification=0 fragment-offset=0 ttl=63 tcp-flags=syn,ack 

13 time=9.508 num=14 direction=tx interface=pppoe-3bbfttx-ether1 src-address=mikrotik.public.ip:80 (http) dst-address=unknown.ip.2:7745 protocol=ip ip-protocol=tcp 
   size=52 cpu=1 fp=no ip-packet-size=52 ip-header-size=20 dscp=0 identification=0 fragment-offset=0 ttl=63 tcp-flags=syn,ack

sindy · Thu May 03, 2018 9:25 pm

There are two unknown ip address here. The unknown.ip.1 is probably one of my fttx isp's server. And unknown.ip.2 is probably my lte carier's server.

The sniffer filter doesn't support complex expressions so packets both to and from port 80 are captured regardless with which address the port 80 is associated. You can see that in the packets with unknown addresses, port 80 is associated with the unknown address and some other port is associated with your Mikrotik's public address. In another words, these packets belong to TCP connections from some clients on your LAN to http servers on these unknown addresses.

But the packets between my.lte.ip:44811 and mikrotik.public.ip:80 follow the same pattern you could see at the server side, i.e. the client keeps retransmitting the SYN packet and the server keeps retransmitting the SYN,ACK response, and as for the addresses and ports, it is a symmetric flow.

So we can see that the dst-nat and "un-dst-nat" work properly, and the Mikrotik does not filter packets as it does forward the server's responses all the way back to the PPPoE WAN interface.

At this stage, the following possibilities remain:

there is something wrong with the TCP headers of the packets - in fact, this could only mean the Seq and Ack values to be corrupt, where the Ack value in the SYN,ACK packet would not match the Seq value in the SYN packet because either the server's TCP stack would have set it incorrectly or because RouterOS would have changed it while forwarding the packet
there is something wrong with the PPPoE functionality, corrupting the packets' contents or checksum or address information
there is something rotten in how your ISP treats the responses from port 80

Possibilities 1 and 2 seem so unlikely to me (why would anything of these happen only for packets to/from port 80) that my personal favourite for the culprit is possibiity 3 although it also seems quite unlikely.

To analyse the Seq and Ack numbers, you would have to sniff to a file and open that file using Wireshark or tcpdump to see this level of packet details, Mikrotik sniffer doesn't show that to you.

Same case is the PPPoE analysis - the PPPoE payload is not encrypted, so Wireshark will dissect it and thus show you whether the encapsulated IP packets are the same like the original ones, but filtering during capture would have to be off and you would have to use display filters of Wireshark to show only the interesting part.

If you could somehow use another Mikrotik connected from outside to sniff packets to and from port 80 of your public address, you could see whether the responses do arrive (which would imply 1 or some kind of 2 to be the problem) or not (which would imply another kind of 2 or 3 to be the problem). In another words, to see whether 2 is a problem or not, you need to capture at your Mikrotik and use Wireshark for analysis in any case, and if you do that, you can also tell whether 1 is the problem.

So suggest the next step. I can analyze the sniff file but obfuscating the IP addresses in that file would be a more complex task for you than to analyze the file yourself. There are tools for that but I'm not sure they can sanitize the payload of the PPPoE packets.

ZartPARZ · Fri May 04, 2018 8:24 am

There are two unknown ip address here. The unknown.ip.1 is probably one of my fttx isp's server. And unknown.ip.2 is probably my lte carier's server.
The sniffer filter doesn't support complex expressions so packets both to and from port 80 are captured regardless with which address the port 80 is associated. You can see that in the packets with unknown addresses, port 80 is associated with the unknown address and some other port is associated with your Mikrotik's public address. In another words, these packets belong to TCP connections from some clients on your LAN to http servers on these unknown addresses.

But the packets between my.lte.ip:44811 and mikrotik.public.ip:80 follow the same pattern you could see at the server side, i.e. the client keeps retransmitting the SYN packet and the server keeps retransmitting the SYN,ACK response, and as for the addresses and ports, it is a symmetric flow.

So we can see that the dst-nat and "un-dst-nat" work properly, and the Mikrotik does not filter packets as it does forward the server's responses all the way back to the PPPoE WAN interface.

At this stage, the following possibilities remain:

there is something wrong with the TCP headers of the packets - in fact, this could only mean the Seq and Ack values to be corrupt, where the Ack value in the SYN,ACK packet would not match the Seq value in the SYN packet because either the server's TCP stack would have set it incorrectly or because RouterOS would have changed it while forwarding the packet

there is something wrong with the PPPoE functionality, corrupting the packets' contents or checksum or address information

there is something rotten in how your ISP treats the responses from port 80
Possibilities 1 and 2 seem so unlikely to me (why would anything of these happen only for packets to/from port 80) that my personal favourite for the culprit is possibiity 3 although it also seems quite unlikely.

To analyse the Seq and Ack numbers, you would have to sniff to a file and open that file using Wireshark or tcpdump to see this level of packet details, Mikrotik sniffer doesn't show that to you.

Same case is the PPPoE analysis - the PPPoE payload is not encrypted, so Wireshark will dissect it and thus show you whether the encapsulated IP packets are the same like the original ones, but filtering during capture would have to be off and you would have to use display filters of Wireshark to show only the interesting part.

If you could somehow use another Mikrotik connected from outside to sniff packets to and from port 80 of your public address, you could see whether the responses do arrive (which would imply 1 or some kind of 2 to be the problem) or not (which would imply another kind of 2 or 3 to be the problem). In another words, to see whether 2 is a problem or not, you need to capture at your Mikrotik and use Wireshark for analysis in any case, and if you do that, you can also tell whether 1 is the problem.

So suggest the next step. I can analyze the sniff file but obfuscating the IP addresses in that file would be a more complex task for you than to analyze the file yourself. There are tools for that but I'm not sure they can sanitize the payload of the PPPoE packets.

Hi, sindy.
Your possibility #3 is correct. My isp block the packet on port 80. They have confirmed this after I call them. Before this case, I believed that if they decide to block the traffic on port 80, they should block incoming traffic. But they block responses from my server, which I think it does not make sense.
Anyway, thank you for your time bearing with me. I have learned a lot from you.

Regards.

ZartPARZ · Fri May 04, 2018 10:26 am

Now, my isp open the port for me. Everything is working fine. Thank you everyone for helping me.

Regards.

Sob · Fri May 04, 2018 2:49 pm

ISP's admin is evil.

If they blocked incoming traffic, it would take you few minutes to find out and be sure about it. When they block only outgoing replies, you waste hours trying to find an error on your side, because you don't expect this. In the end it's pointless, because you ask them eventually anyway. It would be interesting to hear their explanation, why they do it like this.

ZartPARZ · Fri May 04, 2018 5:08 pm

ISP's admin is evil. If they blocked incoming traffic, it would take you few minutes to find out and be sure about it. When they block only outgoing replies, you waste hours trying to find an error on your side, because you don't expect this. In the end it's pointless, because you ask them eventually anyway. It would be interesting to hear their explanation, why they do it like this.

Too bad, the guy who spoke with me was just a technician who has no idea why they block the response instead of incoming packet and who come up with this idea.

Cannot forward port 80 [SOLVED]

Cannot forward port 80

Re: Cannot forward port 80

Re: Cannot forward port 80

Re: Cannot forward port 80

Re: Cannot forward port 80

Re: Cannot forward port 80

Re: Cannot forward port 80

Re: Cannot forward port 80

Re: Cannot forward port 80

Re: Cannot forward port 80

Re: Cannot forward port 80

Re: Cannot forward port 80

Re: Cannot forward port 80

Re: Cannot forward port 80

Re: Cannot forward port 80

Re: Cannot forward port 80

Re: Cannot forward port 80

Re: Cannot forward port 80

Re: Cannot forward port 80

Re: Cannot forward port 80

Re: Cannot forward port 80

Re: Cannot forward port 80

Re: Cannot forward port 80

Re: Cannot forward port 80

Re: Cannot forward port 80

Re: Cannot forward port 80

Re: Cannot forward port 80

Re: Cannot forward port 80 [SOLVED]

Re: Cannot forward port 80

Re: Cannot forward port 80

Re: Cannot forward port 80

Re: Cannot forward port 80