Access Modem GUI Behind Firewall
-
@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..
-
sorry the answers always come a little late
so I have deleted the static route again.
then i checked the routing tbale once see screen shot interface and IP are visible.
I created these any to any in the firewall for the lan rules for IPV4 and IPv6 according to the instructions for the failover setup erv, otherwise I created them separately.
I have selected the failover gateway in the dropdown under advanced in the lan rules I think the firewall will send everything over it can it be because of that ? see screen shot....
I would like to do your steps I'm just stuck at the point where I write I should create a rule about the Policy Based rules which exactly only the outbound nat I have or another ?
I will do the sniff and then send the info. no traffic comes through when I check with packet capture on interface Vigor BGE 1
-
@johnpoz said in Access Modem GUI Behind Firewall:
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.
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..
No you are of course absolutely right, his routing table clearly shows 192.168.5.0/24 as well, and I find it strange that it wouldn't "just work". Very confusing all of it though... and if there is some policy rule as well, I missed that...
A question though... will pfsense process send a request to an unknown IP via the WAN, even if it belongs to an RFC 1918 range? I guess I was thinking it would just drop it?
-
@Gblenn said in Access Modem GUI Behind Firewall:
and I find it strange that it wouldn't "just work".
because as you can see by his lan rules - he is policy routing.. Which has been brought up multiple times already.. He needs a rule to allows the normal routing to work..
Here
https://docs.netgate.com/pfsense/en/latest/multiwan/policy-route.html#bypassing-policy-routing
-
@johnpoz I apologise for asking this question.
I have looked at the instructions, unfortunately I do not understand one point in the instructions it says to create an alias for RFC1918 and in the picture it can also be seen that RFC1918 was set as destination.
but when i want to create a new rule, the destination RF1918 is displayed as invalid IP so i don't quite understand how i can set this i can only set an IP subnet e.g. 192.168.0.0/16
-
@Globaltrader312 Huh.. You don't need to create such an alias you could just put in 192.168.0.0/16 cidr in the rule.. Or just your 192.168.5.1/32 or 192.168.5.0/24
But creating an alias for all rfc1918 space would be done in the alias section
Here would be an example of using it in rule - this isn't a rule like you need but just an example of using the alias in a firewall rule
-
I have now created the rule via the Policy Based Rules and traffic is also flowing see screen shot and packet capture
but the GUI of the Vigor is still not accessible.
can it be that I still have to enter the changed ports from vigor in the firewall 8080 and 444 which I changed because of an advice from another user a few posts before.