Connecting to bridged modem (192.168.178.1)
-
I have trouble getting a webpage back from my bridged modem.
I have my pfsense box placed after my modem that is placed in bridged mode. The modem can still be reached at the IP 192.168.178.1.
I disabled the option to not allow incoming private networks, and added a new rule at the bottom of the floating rules to block private networks at the WAN interface
On the firewall rules floating tab I created a rule to allow icmp to this ip on the wan interface. This is placed above the deny private networks rule.
This is working fine, i get a echo reply from the modemOn the firewall rules floating tab I created a rule to allow http/https to this ip on the wan interface. This is also placed above the deny private networks rule.
This rule is working but does not have the desired outcome.
I can see the rule being hit (states and bytes) an din the fw log I can see the corresponding pass being logged.
However, my browser keeps waiting for a reply and eventually timed out.the firewall log shows no other entries for the 192.168.178.1 (nor on source ip nor on destination ip)
I did a packet capture on WAN (although I do not know realy much about that) and at least saw there were packets leaving to the modem and even an acknoledgement coming back. then a get http from wan to the modem , and after that a lot of tcp retransmission requests.
Is there some other setting I must set or do to be able to receive the http pages from the modem?
-
I disabled the option to not allow incoming private networks, and added a new rule at the bottom of the floating rules to block private networks at the WAN interface
You don't need to do that. That option only applies to unsolicited inbound traffic, such as other users trying to reach your web server you have port-forwarded out for example. When you initiate the traffic by trying to reach the modem, its replies will be allowed back in automatically.
This might help:
https://docs.netgate.com/pfsense/en/latest/interfaces/accessing-modem-from-inside-firewall.html
-
thnx, I looked at the document but this only applies to PPPoE connections :(
(see this topic: Can't Add OPT interface)I did try to set up the NAT-outbound part but that made no difference (did not try the VIP yet)
I did a packet capture when trying to open the http page and this was the result (set level of detail: high)
replaced my external ip with aaa.bbb.ccc.ddd12:37:41.966110 IP (tos 0x0, ttl 127, id 11026, offset 0, flags [DF], proto TCP (6), length 52) aaa.bbb.ccc.ddd.34157 > 192.168.178.1.80: Flags [S], cksum 0x6113 (correct), seq 1093336084, win 65535, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 12:37:41.966443 IP (tos 0x0, ttl 64, id 17729, offset 0, flags [none], proto TCP (6), length 48) 192.168.178.1.80 > aaa.bbb.ccc.ddd.34157: Flags [S.], cksum 0xb88d (correct), seq 3022966024, ack 1093336085, win 16384, options [mss 512,nop,wscale 0], length 0 12:37:41.966800 IP (tos 0x0, ttl 127, id 11027, offset 0, flags [none], proto TCP (6), length 40) aaa.bbb.ccc.ddd.34157 > 192.168.178.1.80: Flags [.], cksum 0x1c9e (correct), seq 1, ack 1, win 1024, length 0 12:37:41.970105 IP (tos 0x0, ttl 127, id 11028, offset 0, flags [none], proto TCP (6), length 308) aaa.bbb.ccc.ddd.34157 > 192.168.178.1.80: Flags [P.], cksum 0xb6e1 (correct), seq 1:269, ack 1, win 1024, length 268: HTTP, length: 268 GET / HTTP/1.1 Accept: text/html, application/xhtml+xml, image/jxr, */* Accept-Language: nl-NL User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko Accept-Encoding: gzip, deflate Host: 192.168.178.1 DNT: 1 Connection: Keep-Alive 12:37:42.281930 IP (tos 0x0, ttl 127, id 11029, offset 0, flags [none], proto TCP (6), length 308) aaa.bbb.ccc.ddd.34157 > 192.168.178.1.80: Flags [P.], cksum 0xb6e1 (correct), seq 1:269, ack 1, win 1024, length 268: HTTP, length: 268 GET / HTTP/1.1 Accept: text/html, application/xhtml+xml, image/jxr, */* Accept-Language: nl-NL User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko Accept-Encoding: gzip, deflate Host: 192.168.178.1 DNT: 1 Connection: Keep-Alive 12:37:42.893566 IP (tos 0x0, ttl 127, id 11030, offset 0, flags [none], proto TCP (6), length 308) aaa.bbb.ccc.ddd.34157 > 192.168.178.1.80: Flags [P.], cksum 0xb6e1 (correct), seq 1:269, ack 1, win 1024, length 268: HTTP, length: 268 GET / HTTP/1.1 Accept: text/html, application/xhtml+xml, image/jxr, */* Accept-Language: nl-NL User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko Accept-Encoding: gzip, deflate Host: 192.168.178.1 DNT: 1 Connection: Keep-Alive 12:37:44.102567 IP (tos 0x0, ttl 127, id 11031, offset 0, flags [none], proto TCP (6), length 308) aaa.bbb.ccc.ddd.34157 > 192.168.178.1.80: Flags [P.], cksum 0xb6e1 (correct), seq 1:269, ack 1, win 1024, length 268: HTTP, length: 268 GET / HTTP/1.1 Accept: text/html, application/xhtml+xml, image/jxr, */* Accept-Language: nl-NL User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko Accept-Encoding: gzip, deflate Host: 192.168.178.1 DNT: 1 Connection: Keep-Alive 12:37:44.959278 IP (tos 0x0, ttl 64, id 17730, offset 0, flags [none], proto TCP (6), length 48) 192.168.178.1.80 > aaa.bbb.ccc.ddd.34157: Flags [S.], cksum 0xb88d (correct), seq 3022966024, ack 1093336085, win 16384, options [mss 512,nop,wscale 0], length 0 12:37:44.959667 IP (tos 0x0, ttl 127, id 11032, offset 0, flags [none], proto TCP (6), length 40) aaa.bbb.ccc.ddd.34157 > 192.168.178.1.80: Flags [.], cksum 0x1b92 (correct), seq 269, ack 1, win 1024, length 0 12:37:46.511367 IP (tos 0x0, ttl 127, id 11033, offset 0, flags [none], proto TCP (6), length 308) aaa.bbb.ccc.ddd.34157 > 192.168.178.1.80: Flags [P.], cksum 0xb6e1 (correct), seq 1:269, ack 1, win 1024, length 268: HTTP, length: 268 GET / HTTP/1.1 Accept: text/html, application/xhtml+xml, image/jxr, */* Accept-Language: nl-NL User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko Accept-Encoding: gzip, deflate Host: 192.168.178.1 DNT: 1 Connection: Keep-Alive 12:37:50.960804 IP (tos 0x0, ttl 64, id 17731, offset 0, flags [none], proto TCP (6), length 48) 192.168.178.1.80 > aaa.bbb.ccc.ddd.34157: Flags [S.], cksum 0xb88d (correct), seq 3022966024, ack 1093336085, win 16384, options [mss 512,nop,wscale 0], length 0 12:37:50.961105 IP (tos 0x0, ttl 127, id 11034, offset 0, flags [none], proto TCP (6), length 40) aaa.bbb.ccc.ddd.34157 > 192.168.178.1.80: Flags [.], cksum 0x1b92 (correct), seq 269, ack 1, win 1024, length 0 12:37:51.316782 IP (tos 0x0, ttl 127, id 11035, offset 0, flags [none], proto TCP (6), length 308) aaa.bbb.ccc.ddd.34157 > 192.168.178.1.80: Flags [P.], cksum 0xb6e1 (correct), seq 1:269, ack 1, win 1024, length 268: HTTP, length: 268 GET / HTTP/1.1 Accept: text/html, application/xhtml+xml, image/jxr, */* Accept-Language: nl-NL User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko Accept-Encoding: gzip, deflate Host: 192.168.178.1 DNT: 1 Connection: Keep-Alive 12:38:00.927457 IP (tos 0x0, ttl 127, id 11036, offset 0, flags [none], proto TCP (6), length 40) aaa.bbb.ccc.ddd.34157 > 192.168.178.1.80: Flags [R.], cksum 0x1f8e (correct), seq 269, ack 1, win 0, length 0
My rules on the floating rules tab (all on the WAN interface):
As you can see, my second rule in the picture is being hit (now 0 states and 2 kb, but was 2 states)
If I look at the packet capture it almost looks like there is never a packet from the modem that makes it back to the pfsense (wan) port?
-
If you still have an Allow All rule on your LAN then that would be sufficient to reach your modem and for it to answer.
Some modems will not answer for traffic to their GUI from outside their own LAN subnet. That's where you have to get creative.
Ziggo looks to be cable. Right? Do you have to use PPPoe on your WAN or is it simply DHCP?
-
@chpalmer you are right, Ziggo is a cable company.
the modem uses dhcp, not pppoe. -
If you cannot reach that modem then it most likely is designed not to respond out of its own subnet.
Is there a page on your modem to set its address?
Can you show it?
Here you can clearly see my modem answers me without any changes to my router config.
C:>ping 192.168.100.1
Pinging 192.168.100.1 with 32 bytes of data:
Reply from 192.168.100.1: bytes=32 time=2ms TTL=63
Reply from 192.168.100.1: bytes=32 time=2ms TTL=63
Reply from 192.168.100.1: bytes=32 time=2ms TTL=63
Reply from 192.168.100.1: bytes=32 time=2ms TTL=63Ping statistics for 192.168.100.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 2ms, Maximum = 2ms, Average = 2msAnd my first hop past my modem..
C:>ping 24.113.35.1
Pinging 24.113.35.1 with 32 bytes of data:
Reply from 24.113.35.1: bytes=32 time=9ms TTL=63
Reply from 24.113.35.1: bytes=32 time=12ms TTL=63
Reply from 24.113.35.1: bytes=32 time=19ms TTL=63
Reply from 24.113.35.1: bytes=32 time=28ms TTL=63Ping statistics for 24.113.35.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 9ms, Maximum = 28ms, Average = 17msShows the modem is not routed through my ISP equipment as shown by the difference in ping times. It is a local resource to my router.
-
The modem ia actually a calbe-modem/router that is set to bridge mode by Ziggo. I let it set to bridge mode so I can use my pfSense box as the router/firewall/etc and not have to deal with double nat.
The only way I am able to connect to the modem now is by its default ip adress that all those modems have when put in bridged mode: 192.168.178.1
Since I can not reach that page I can not show it.I can do a ping and get a reply:
d:\>ping 192.168.178.1 Pinging 192.168.178.1 with 32 bytes of data: Reply from 192.168.178.1: bytes=32 time=1ms TTL=63 Reply from 192.168.178.1: bytes=32 time=1ms TTL=63 Reply from 192.168.178.1: bytes=32 time=1ms TTL=63 Reply from 192.168.178.1: bytes=32 time=1ms TTL=63
as you can see a ping of 1 ms, so also not routed through my isp
-
So that shows me they have your modems GUI page unreachable by a setting on their end.
Can you plug a computer direct into the modem and see the GUI? I bet not.
Set your computer to 192.168.178.2/30 and try that.
Your ping proves you have access.