Access Modem GUI Behind Firewall
-
@Globaltrader312 said in Access Modem GUI Behind Firewall:
ARP table for a while but not permanently.
why would you think it should be perm? The default arp cache is 20 minutes in freebsd/pfsense..
Why are you creating a floating rule? You don't need a floating rule, and you don't need your rule above your lock out rule.. Jut place your rule on your lan above your policy routing rules.
Here maybe this will help you understand what is happening.. Here is my setup to access my modems gui IP 192.168.100.1, since my pfsense gets public IP on its wan.
Created a vip (another IP on the interface) 192.168.100.2
Switched to hybrid nat so could setup outbound nat so traffic wanting to go to 192.168.100.1 was natted to my 192.168.100.2 address
My rules do not do any policy routing and allow the traffic just via normal default lan any any rule.
-
So I have now created a virtual IP with 192.168.5.4/24, which is one from the vigor subnet if I have understood it correctly, this should be correct.
then i created an outbound nat rule. i just can't enter 192.168.5.1/24 the pfsense always changes it to 192.168.5.0/24
Unfortunately it still does not work.
one thing is still not clear to me i have not created any special policy based rules but there are only the anti lockout rule and the two any to any rules and nothing more.
Which rule would I have to create so that I have access to the modem?
-
@Globaltrader312
I have never used PPPoE but why do you have two separate interfaces for the WAN and the VIGOR device? Seems they are based on the igb1 interface but PPPoE sais igb1.7.I get that the VIGOR device is in MODEM mode and simply passes the public IP through to pfsense. When I had an LTE router that was working in bridge mode (modem mode) all I had to do was to create a static route to that IP/32.
Destination : 192.168.5.1 /32
Gateway : VIGOR
Description : Static route to modem UI -
i followed the instructions and there i understood it like this because pppoe only has a virtual inertafce so pppoe1 on bge 1 i have to set a second interface on bge 1 with vigor static ipv4 192.168.5.3/24 1.7 is only vlan tag 7 for dialling in to Vodafone DSL
-
@Globaltrader312 said in Access Modem GUI Behind Firewall:
So I have now created a virtual IP with 192.168.5.4/24,
I didn't say to do that - I did that because my wan interface already had a public IP on it, I do not use PPPoe..
You need an IP that can talk to 192.168.5.1 on the physical interface that is connected to your device that your PPPoe runs on..
Do you also need a vlan tag??
-
@johnpoz
then i misunderstood that i thought that would be the solution
i added the interface vigor to bge 0 and gave this interface the ip 192.168.5.3 and with this and the outbound nat rule it does not work.i thought if i did exactly that it would work.
with my other interface where i use DHCP to get the fixed IP from the ISP i can access the modem without extra rules but not with the SVDSL MOdem.
yes i need vlan tag 7 therefor the interface is 1,7
pppoe runs on bge1 / ppoe1 and the interface vigor too -
@Globaltrader312 said in Access Modem GUI Behind Firewall:
yes i need vlan tag 7 therefor the interface is 1,7
you need a vlan tag for pppoe, but do you need it to just talk to the devices IP?? That seems unlikely to me.
Forget pppoe for a second. If you connect just say a laptop to this vigor device.. Does it get a 192.168.5.x address? If so then there is no tagging needed.
-
@johnpoz said in Access Modem GUI Behind Firewall:
you need a vlan tag for pppoe, but do you need it to just talk to the devices IP?? That seems unlikely to me.
Forget pppoe for a second. If you connect just say a laptop to this vigor device.. Does it get a 192.168.5.x address? If so then there is no tagging needed.
VLAN Tag 7 is only required for dialling in to the ISP to get internet and also the public IP.
no VLAN TAG needed for 192.168.5.1 /24
if I connect my macbook to the VIGOR directly then I only have to manually set the IP 192.168.5.5 or similar once then DNS 192.168.5.1 and then I can access it directly.
-
@Globaltrader312 said in Access Modem GUI Behind Firewall:
no VLAN TAG needed for 192.168.5.1 /24
Well then why did you say you set a vlan
yes i need vlan tag 7 therefor the interface is 1,7
On the interface you created that has the 192.168.5.2 address?
-
I have the VLAN Tag 7 only on the interface 1.7 nowhere else.
I have created the interface Vigor for the connection to the modem and this interface has the IP 192.168.5.2/24 see screen shot
-
@Globaltrader312 so sniff on your vigor interface when you ping this 192.168.5.1 address from a client on your lan... Do you see the traffic go out, is it natted to your vigor address.. Which you have now changed from .2 to .3
Do you see a response?
So for example, here I am pinging that 192.168.100.1 address from device on my network.. You can see it is natted to the pfsense wan address I created of 192.168.100.2
If you do not see the pings going out at least, then no it not going to work because you got something not quite right in your setup, be it your outbound nat, be it your firewall rules with your policy routing.
If you do see it going out properly natted to your vigor IP you set, but no response - then something on your vigor device is not answering.
What firewall rules do you have in floating - could you have something blocking the traffic? I for example have a rule that blocks rfc1918 from leaving my wan, just being a good netizen - no reason to send rfc1918 traffic to my isp/internet if I typo something that is not one of my local networks. or my work laptop likes to try and talk to work IP and if the vpn is not up on it - it would just route out to my isp.
As to the reply-to being disabled.. You might also need to set this.. But maybe not since you don't have a vip setup.. But the sniff should tell us if traffic is indeed going out the proper interface and being natted to your IP so that your device can answer.
-
I get an output but only for pppoe
12:01:43.248512 PPPoE [ses 0x1d34] IP 151.189.146.134 > 1.0.0.1: ICMP echo request, id 18229, seq 138, length 9
12:01:43.259629 PPPoE [ses 0x1d34] IP 1.0.0.1 > 151.189.146.134: ICMP echo reply, id 18229, seq 138, length 9
12:01:47.452219 PPPoE [ses 0x1d34] IP 185.242.226.39.60608 > 151.189.146.134.4730: tcp 0
12:01:49.053355 PPPoE [ses 0x1d34] IP 43.133.5.165.23340 > 151.189.146.134.8466: tcp 0
12:01:53.278537 PPPoE [ses 0x1d34] IP 151.189.146.134 > 1.0.0.1: ICMP echo request, id 18229, seq 139, length 9
12:01:53.289657 PPPoE [ses 0x1d34] IP 1.0.0.1 > 151.189.146.134: ICMP echo reply, id 18229, seq 139, length 9
12:01:53.308097 PPPoE [ses 0x1d34] IP 151.189.146.134.57683 > 44.241.222.240.8883: tcp 31
12:01:53.483017 PPPoE [ses 0x1d34] IP 44.241.222.240.8883 > 151.189.146.134.57683: tcp 31
12:01:53.483817 PPPoE [ses 0x1d34] IP 151.189.146.134.57683 > 44.241.222.240.8883: tcp 0
12:01:55.589428 PPPoE [ses 0x1d34] IP 44.208.52.45.6126 > 151.189.146.134.5070: tcp 0
12:01:55.589639 PPPoE [ses 0x1d34] IP 151.189.146.134.5070 > 44.208.52.45.6126: tcp 0
12:02:01.834287 PPPoE [ses 0x1d34] IP 117.174.160.228.42601 > 151.189.146.134.23: tcp 0
12:02:03.314210 PPPoE [ses 0x1d34] IP 151.189.146.134 > 1.0.0.1: ICMP echo request, id 18229, seq 140, length 9
12:02:03.325174 PPPoE [ses 0x1d34] IP 1.0.0.1 > 151.189.146.134: ICMP echo reply, id 18229, seq 140, length 9
12:02:05.033714 PPPoE [ses 0x1d34] IP 167.94.146.24.46489 > 151.189.146.134.102: tcp 0
12:02:05.718028 PPPoE [ses 0x1d34] IP 185.242.226.39.53318 > 151.189.146.134.5006: tcp 0
12:02:09.529158 PPPoE [ses 0x1d34] IP 37.44.238.80.52849 > 151.189.146.134.8728: tcp 0
12:02:13.582482 PPPoE [ses 0x1d34] IP 151.189.146.134 > 1.0.0.1: ICMP echo request, id 18229, seq 141, length 9
12:02:13.593298 PPPoE [ses 0x1d34] IP 1.0.0.1 > 151.189.146.134: ICMP echo reply, id 18229, seq 141, length 9
12:02:16.070903 PPPoE [ses 0x1d34] IP 44.208.52.45.6126 > 151.189.146.134.5070: tcp 0
12:02:16.071133 PPPoE [ses 0x1d34] IP 151.189.146.134.5070 > 44.208.52.45.6126: tcp 0
12:02:23.308265 PPPoE [ses 0x1d34] IP 151.189.146.134.57683 > 44.241.222.240.8883: tcp 31
12:02:23.483635 PPPoE [ses 0x1d34] IP 44.241.222.240.8883 > 151.189.146.134.57683: tcp 31
12:02:23.484442 PPPoE [ses 0x1d34] IP 151.189.146.134.57683 > 44.241.222.240.8883: tcp 0
12:02:23.699264 PPPoE [ses 0x1d34] IP 151.189.146.134 > 1.0.0.1: ICMP echo request, id 18229, seq 142, length 9
12:02:23.710379 PPPoE [ses 0x1d34] IP 1.0.0.1 > 151.189.146.134: ICMP echo reply, id 18229, seq 142, length 9
12:02:25.391770 PPPoE [ses 0x1d34] IP 37.48.118.242.993 > 151.189.146.134.37210: tcp 46
12:02:25.392288 PPPoE [ses 0x1d34] IP 151.189.146.134.37210 > 37.48.118.242.993: tcp 0
12:02:25.397405 PPPoE [ses 0x1d34] IP 37.48.118.242.993 > 151.189.146.134.52452: tcp 46
12:02:25.397770 PPPoE [ses 0x1d34] IP 151.189.146.134.52452 > 37.48.118.242.993: tcp 0
12:02:25.402436 PPPoE [ses 0x1d34] IP 37.48.118.242.143 > 151.189.146.134.57083: tcp 46
12:02:25.402786 PPPoE [ses 0x1d34] IP 151.189.146.134.57083 > 37.48.118.242.143: tcp 0
12:02:25.410150 PPPoE [ses 0x1d34] IP 37.48.118.242.993 > 151.189.146.134.49770: tcp 46
12:02:25.410517 PPPoE [ses 0x1d34] IP 151.189.146.134.49770 > 37.48.118.242.993: tcp 0
12:02:25.412480 PPPoE [ses 0x1d34] IP 37.48.118.242.143 > 151.189.146.134.47561: tcp 46
12:02:25.412849 PPPoE [ses 0x1d34] IP 151.189.146.134.47561 > 37.48.118.242.143: tcp 0
12:02:25.422163 PPPoE [ses 0x1d34] IP 37.48.118.242.143 > 151.189.146.134.32577: tcp 46
12:02:25.422517 PPPoE [ses 0x1d34] IP 151.189.146.134.32577 > 37.48.118.242.143: tcp 0
12:02:25.424182 PPPoE [ses 0x1d34] IP 37.48.118.242.993 > 151.189.146.134.25629: tcp 46
12:02:25.424541 PPPoE [ses 0x1d34] IP 151.189.146.134.25629 > 37.48.118.242.993: tcp 0
12:02:25.433705 PPPoE [ses 0x1d34] IP 37.48.118.242.993 > 151.189.146.134.41763: tcp 46
12:02:25.433712 PPPoE [ses 0x1d34] IP 37.48.118.242.143 > 151.189.146.134.60197: tcp 46
12:02:25.433854 PPPoE [ses 0x1d34] IP 37.48.118.242.143 > 151.189.146.134.47351: tcp 46
12:02:25.434048 PPPoE [ses 0x1d34] IP 151.189.146.134.60197 > 37.48.118.242.143: tcp 0
12:02:25.434050 PPPoE [ses 0x1d34] IP 151.189.146.134.41763 > 37.48.118.242.993: tcp 0
12:02:25.434066 PPPoE [ses 0x1d34] IP 151.189.146.134.47351 > 37.48.118.242.143: tcp 0
12:02:25.461684 PPPoE [ses 0x1d34] IP 37.48.118.242.143 > 151.189.146.134.32811: tcp 46
12:02:25.462067 PPPoE [ses 0x1d34] IP 151.189.146.134.32811 > 37.48.118.242.143: tcp 0
12:02:25.462380 PPPoE [ses 0x1d34] IP 37.48.118.242.143 > 151.189.146.134.5724: tcp 46
12:02:25.462386 PPPoE [ses 0x1d34] IP 37.48.118.242.993 > 151.189.146.134.37184: tcp 46
12:02:25.462531 PPPoE [ses 0x1d34] IP 37.48.118.242.993 > 151.189.146.134.8706: tcp 46
12:02:25.462654 PPPoE [ses 0x1d34] IP 151.189.146.134.5724 > 37.48.118.242.143: tcp 0
12:02:25.462667 PPPoE [ses 0x1d34] IP 151.189.146.134.37184 > 37.48.118.242.993: tcp 0
12:02:25.462801 PPPoE [ses 0x1d34] IP 151.189.146.134.8706 > 37.48.118.242.993: tcp 0
12:02:25.465215 PPPoE [ses 0x1d34] IP 37.48.118.242.143 > 151.189.146.134.50593: tcp 46
12:02:25.465571 PPPoE [ses 0x1d34] IP 151.189.146.134.50593 > 37.48.118.242.143: tcp 0
12:02:25.465884 PPPoE [ses 0x1d34] IP 37.48.118.242.993 > 151.189.146.134.51619: tcp 46
12:02:25.466227 PPPoE [ses 0x1d34] IP 151.189.146.134.51619 > 37.48.118.242.993: tcp 0everything works on the vigor itself i had a UI Edge Router 12 and 6P before and i also had a Mutlwi WAN and failover setup there and i only had to set up a source nat and i can access it.
the only difference was that with the ER I had to use an extra lin interface where a second cable went to the VIGOR because the ER supports this with 2 interfaces on one ETH interface.
as far as the floating rule is concerned, I deleted it again because you said it wasn't necessary
I only have an outbount nat rule.
-
@Globaltrader312 Why would your outbound nat rule be on wan2.. Your interface is the vigor interface.. this is the physical interface that you put the 5.x address on that connects to the vigor device.
Your nat should be natting to that interface..
And for your sniff, set a host to 192.168.5.1 - the destination address your waning to talk too.. You don't need to see any other noise..
You create the interface per the instructions, since your pppoe. You put an IP on it, you nat to this IP..
Here is what I would do - pull out everything you have randomly clicked on to try and get this to work.. Follow the instructions. Create an interface. Put the IP on it, change to hybrid nat and setup an outbound nat for going to this 5.1 address to be natted to the interface IP you created.
These is the 2 steps defined in the instructions.
Where your setup differs is you have multiple wan interfaces, and your policy routing. So you need a rule on the interface where your traffic is going to come into pfsense that wants to talk to the vigor device. This rule needs to be above where you policy route out some specific gateway, be it a load balancer, a failover group or whatever.
Make sure there are no rules in floating that would interfere with your traffic. Also this 192.168.5 your wanting to talk to - this can not overlap with your lan network, nor any other local network you have attached to pfsense.
Now sniff on the vigor interface, with a host filter IP of 192.168.5.1 (your IP your wanting to talk to from this interface).. Do you see traffic going out, natted to the 192.168.5.x address you put on the pfsense interface you created.
-
@johnpoz said in Access Modem GUI Behind Firewall:
Your nat should be natting to that interface..
And for your sniff, set a host to 192.168.5.1 - the destination address your waning to talk too.. You don't need to see any other noise..
You create the interface per the instructions, since your pppoe. You put an IP on it, you nat to this IP..
Here is what I would do - pull out everything you have randomly clicked on to try and get this to work.. Follow the instructions. Create an interface. Put the IP on it, change to hybrid nat and setup an outbound nat for going to this 5.1 address to be natted to the interface IP you created.
These is the 2 steps defined in the instructions.
Where your setup differs is you have multiple wan interfaces, and your policy routing. So you need a rule on the interface where your traffic is going to come into pfsense that wants to talk to the vigor device. This rule needs to be above where you policy route out some specific gateway, be it a load balancer, a failover group or whatever.
Make sure there are no rules in floating that would interfere with your traffic. Also this 192.168.5 your wanting to talk to - this can not overlap with your lan network, nor any other local network you have attached to pfsense.
Now sniff on the vigor interface, with a host filter IP of 192.168.5.1 (your IP your wanting to talk to from this interface).. Do you see traffic going out, natted to the 192.168.5.x address you put on the pfsense interface you created.
I have done the following
I created an INterface again with the name VIGOR then gave the interface the IP address with 192.168.5.3 then I created the Outbount NAT Rule as in the instructions as in the screenshot unfortunately it only lets me enter 192.168.5.0/24 for Destination it always changes this after saving.
for Translation address I entered 192.168.5.3 which is the one from the Vigor interface.
As far as the rules about the Policy Based rules are concerned, I am currently stuck there, so I only have the two any to any rules and of course the gateway is specified there, the Failover GW where all 3 WANs are included as tier 1 2 3.
if I have understood it correctly, an extra rule has to be created there again, right ? only which one
-
@Globaltrader312 Why are you showing rules on wan2 - this has zero to do with anything.
Maybe this is all a translation issue?
Maybe you should ask for help in your native language section, because we seem to not be able to communicate??
As to changing your destination in an outbound nat - if you set the mask to /24 then yeah it prob changes the last octet to .0 - if you want to set the specific IP then the mask would be /32
edit: an an any any rule on a wan, is never going to be a good idea.
-
@Globaltrader312 Btw: The NAT Outbound rule is on the VIGOR interface, as per docu.
-
@Globaltrader312 said in Access Modem GUI Behind Firewall:
@johnpoz
then i misunderstood that i thought that would be the solution
i added the interface vigor to bge 0 and gave this interface the ip 192.168.5.3 and with this and the outbound nat rule it does not work.i thought if i did exactly that it would work.
with my other interface where i use DHCP to get the fixed IP from the ISP i can access the modem without extra rules but not with the SVDSL MOdem.
yes i need vlan tag 7 therefor the interface is 1,7
pppoe runs on bge1 / ppoe1 and the interface vigor too@patient0 How do you access the UI of the modem for WAN1 where you seem to have a public IP (DHCP)?
Have you tried creating a static route for 192.168.5.1 /32, using the VIGOR interface as the Gateway in the setup?
-
I have a static public IP on WAN 1 which I have been assigned by my cable provider in the business tariff via DHCP via my cable modem.
is a dual stack IPV4 and IPV6the modem IP of the technicolor TC4400 is 192.168.100.1 is connected to WAN 1 BGE0 when I open it it works without extra rules or anything else.
See screenshot
-
@Globaltrader312 Ok so pfsense simply routes that request out the WAN1 then. I assumed it would never try to route an unknown private IP out the WAN... ??
I wonder though, the VIGOR interface isn't part of your load balancing or failover setup is it?? It's not a gateway at all actually... So then the only way for pfsense to actually route any traffic that way would be to specifically tell it.
Set up a static route, under System / Routing / Static Routes... create one with :
Destination network : 192.168.5.1 / 32
Gateway : VIGOR interface -
@Globaltrader312 yeah sometimes you don't need an IP or nat. My old modem use to answer with no need for a different interface IP on the 192.168.100 network.. It would intercept the traffic sent out the wan because it was to 192.168.100.1 and send the answer back to the source IP which was just my public IP.
But even if that was the case, natting to an IP that is on the network you want to talk to isn't going to break anything.. But you seemed confused on where you want to set it and what rules you need..
if your vigor interface bge1 is connected to the vigor device, and this device has an IP of 192.168.5.1 and you put an IP of 192.168.5.x on your bge1 interface.. Pfsense knows how to get there.. You need to nat it because its quite possible if your source is say 192.168.1.x the vigor devices isn't going to send the answer back to your 192.168.5.2 IP.
You don't seem able or willing to follow simple instructions or provide info asked for.. Why in the world would you create an any any rule on your wan2 for trying to talk to something connected to bge1 interface?? Just at a complete loss..
This takes all of 2 seconds to validate you your setup.. Sniff on bge1 - does pfsense send the traffic out this interface? Does it nat to your 192.168.5.x address. If it is not - then you got something wrong in what you setup in pfsense.. Its just that simple..
This is step one - because if your not sending traffic out your bge1 interface - how do you expect to talk to an IP on the other end of the wire you have connected to bge1?
Set up a static route, under System / Routing / Static Routes... create one with :
You do not need a route.. If pfsense has an interface connected to network X.. Why would it send traffic out any other gateway be it default or not when it has an interface attached to that network?
Unless you had a specific route, to this 192.168.5.X address it would always pick the interface it has in network 192.168.5.x
Viewing the routing table in pfsense could be helpful info.. But there is zero reason to create a route, unless he has created a route with a better route for 192.168.5 out some other interface.
Here is my routes - why would it send traffic out the default for any of the networks its directly attached too?
See the route for 192.168.100.0/24 - that is the network its attached to via the VIP I created on mine, etc..
If he is sending the traffic out some other interface because of policy routing then no its never going to work.. But create a route isn't going to fix his policy routing rule that would be sending traffic out the wrong gateway... He just needs a rule above his policy route that allows the traffic and uses pfsense normal routing..
