Get public ip for pcs
-
In a virtual machine with public ip it works because the two machines are connected on the same bridge. But if you try to access it from the outside, i can't.
It should probably be something on the pfsense firewall but in the firewall logs nothing is blocked on port 80.
-
How are those servers getting their IP? Statically configured?
If so the ISP is going to be ARPing for those IPs on the WAN and you should see that in a packet capture.
Can the servers connect out?
Steve
-
The servers get the ips through DHCP from my ISP I created a bridge from wan to lan.
pfsense has a public ip public through DHCP and this already works outside the network.The ips that are on the pfsense bridge does not work outside the network, only inside.
-
Ok, if the servers are pulling a DHCP lease correctly then the bridge is working.
Can the servers connect out to public IPs?
Your pass rules are TCP/UDP only so ping will not work.Steve
-
yes the bridge works.
I already added the icmp and the ping works to connect to public servers.
the only problem is that the ports are not open to the outside of these ips on the servers.
but on the firewall they are open and in the logs nothing to block appears. -
Run a packet capture on the WAN for one of the server IPs. Try to connect to it. What do you see?
-
no port
13:32:29.317735 IP 79.124.62.98.8080 > 176.79.22.208.64030: tcp 0
13:32:29.318082 IP 176.79.22.208.64030 > 79.124.62.98.8080: tcp 0
13:32:29.701921 IP 104.211.136.118.42248 > 176.79.22.208.6379: tcp 0
13:32:29.702123 IP 176.79.22.208.6379 > 104.211.136.118.42248: tcp 0
13:32:30.465707 IP 79.124.62.98.8080 > 176.79.22.208.8576: tcp 0
13:32:30.465943 IP 176.79.22.208.8576 > 79.124.62.98.8080: tcp 0
13:32:31.388806 IP 79.124.62.74.8080 > 176.79.22.208.6321: tcp 0
13:32:31.389043 IP 176.79.22.208.6321 > 79.124.62.74.8080: tcp 0
13:32:33.209124 IP 79.124.62.98.8080 > 176.79.22.208.57090: tcp 0
13:32:33.209345 IP 176.79.22.208.57090 > 79.124.62.98.8080: tcp 0
13:32:34.526102 IP 79.124.62.98.8080 > 176.79.22.208.8337: tcp 0
13:32:34.526297 IP 176.79.22.208.8337 > 79.124.62.98.8080: tcp 0
13:32:34.532040 ARP, Request who-has 176.79.22.1 tell 176.79.22.208, length 46
13:32:34.532922 ARP, Reply 176.79.22.1 is-at 00:03:fa:00:00:01, length 46
13:32:36.055518 IP 79.124.62.74.8080 > 176.79.22.208.1340: tcp 0
13:32:36.055728 IP 176.79.22.208.1340 > 79.124.62.74.8080: tcp 0
13:32:37.972712 IP 79.124.62.98.8080 > 176.79.22.208.8009: tcp 0
13:32:37.972919 IP 176.79.22.208.8009 > 79.124.62.98.8080: tcp 0
13:32:40.439980 IP 79.124.62.98.8080 > 176.79.22.208.20049: tcp 0
13:32:40.440203 IP 176.79.22.208.20049 > 79.124.62.98.8080: tcp 0
13:32:43.711008 IP 162.142.125.91.63264 > 176.79.22.208.16061: tcp 0
13:32:43.711217 IP 176.79.22.208.16061 > 162.142.125.91.63264: tcp 0witch port 80
13:34:42.227724 IP 176.79.25.173.53915 > 176.79.22.208.80: tcp 0
13:34:42.227954 IP 176.79.22.208.80 > 176.79.25.173.53915: tcp 0
13:34:42.229700 IP 176.79.25.173.59211 > 176.79.22.208.80: tcp 0
13:34:42.229849 IP 176.79.22.208.80 > 176.79.25.173.59211: tcp 0
13:34:42.540794 IP 176.79.25.173.61377 > 176.79.22.208.80: tcp 0
13:34:42.540998 IP 176.79.22.208.80 > 176.79.25.173.61377: tcp 0
13:34:43.191201 IP 176.79.25.173.59211 > 176.79.22.208.80: tcp 0
13:34:43.191309 IP 176.79.25.173.53915 > 176.79.22.208.80: tcp 0
13:34:43.191405 IP 176.79.22.208.80 > 176.79.25.173.59211: tcp 0
13:34:43.191509 IP 176.79.22.208.80 > 176.79.25.173.53915: tcp 0
13:34:43.447009 IP 176.79.25.173.61377 > 176.79.22.208.80: tcp 0
13:34:43.447285 IP 176.79.22.208.80 > 176.79.25.173.61377: tcp 0
13:34:44.195234 IP 176.79.22.208.80 > 176.79.25.173.53915: tcp 0
13:34:44.195247 IP 176.79.22.208.80 > 176.79.25.173.59211: tcp 0
13:34:44.451104 IP 176.79.22.208.80 > 176.79.25.173.61377: tcp 0
13:34:45.220337 IP 176.79.25.173.59211 > 176.79.22.208.80: tcp 0
13:34:45.220355 IP 176.79.25.173.53915 > 176.79.22.208.80: tcp 0
13:34:45.220578 IP 176.79.22.208.80 > 176.79.25.173.59211: tcp 0
13:34:45.220592 IP 176.79.22.208.80 > 176.79.25.173.53915: tcp 0
13:34:45.463846 IP 176.79.25.173.61377 > 176.79.22.208.80: tcp 0
13:34:45.464016 IP 176.79.22.208.80 > 176.79.25.173.61377: tcp 0
13:34:47.235101 IP 176.79.22.208.80 > 176.79.25.173.53915: tcp 0
13:34:47.235115 IP 176.79.22.208.80 > 176.79.25.173.59211: tcp 0
13:34:47.491289 IP 176.79.22.208.80 > 176.79.25.173.61377: tcp 0
13:34:49.283230 IP 176.79.25.173.59211 > 176.79.22.208.80: tcp 0
13:34:49.283337 IP 176.79.25.173.53915 > 176.79.22.208.80: tcp 0
13:34:49.283432 IP 176.79.22.208.80 > 176.79.25.173.59211: tcp 0
13:34:49.283537 IP 176.79.22.208.80 > 176.79.25.173.53915: tcp 0
13:34:49.527594 IP 176.79.25.173.61377 > 176.79.22.208.80: tcp 0
13:34:49.527794 IP 176.79.22.208.80 > 176.79.25.173.61377: tcp 0 -
Mmm, well it sure looks like two way traffic there.
That's on the pfSense WAN interface?
.208 IP is the server there? What subnet mask does it have?
I assume the .173 IP is not in the same subnet?Steve
-
The ips that are assigned are from different subnets depending on the availability of the isp.
the mask is /24
Yes that was in the wan interface. But I send it again to be sure.
Yes the 208 was that which was assigned to the server.13:47:46.315025 IP 79.124.62.98.8080 > 176.79.22.208.9182: tcp 0
13:47:48.432381 IP 79.124.62.74.8080 > 176.79.22.208.7991: tcp 0
13:47:49.522016 IP 184.105.139.73.36267 > 176.79.22.208.1900: UDP, length 97
13:47:52.030703 IP 124.236.24.85.47070 > 176.79.22.208.6379: tcp 0
13:47:53.383760 IP 79.124.62.74.8080 > 176.79.22.208.4610: tcp 0
13:47:55.757211 IP 79.124.62.98.8080 > 176.79.22.208.60077: tcp 0
13:47:58.799248 IP 79.124.62.98.8080 > 176.79.22.208.9216: tcp 0
13:48:00.335677 IP 79.124.62.98.8080 > 176.79.22.208.17101: tcp 0
13:48:03.365632 IP 79.124.62.74.8080 > 176.79.22.208.6711: tcp 0
13:48:03.413042 IP 79.124.62.98.8080 > 176.79.22.208.8834: tcp 0
13:48:07.343710 IP 79.124.62.74.8080 > 176.79.22.208.6010: tcp 0
13:48:13.070336 IP 74.120.14.81.65353 > 176.79.22.208.10086: tcp 0
13:48:15.135572 IP 79.124.62.74.8080 > 176.79.22.208.5791: tcp 0
13:48:19.020341 IP 79.124.62.98.8080 > 176.79.22.208.8335: tcp 0
13:48:19.640324 IP 79.124.62.74.8080 > 176.79.22.208.5041: tcp 0
13:48:21.996482 IP 79.124.62.98.8080 > 176.79.22.208.55083: tcp 0
13:48:38.087428 IP 79.124.62.98.8080 > 176.79.22.208.65023: tcp 0
13:48:39.276277 IP 79.124.62.74.8080 > 176.79.22.208.7986: tcp 0
13:48:41.152029 IP 79.124.62.98.8080 > 176.79.22.208.15087: tcp 0
13:48:41.246138 IP 185.189.167.57.33361 > 176.79.22.208.33389: tcp 0
13:48:41.964394 IP 193.242.145.106.40801 > 176.79.22.208.4087: tcp 0
13:48:47.408662 IP 79.124.62.74.8080 > 176.79.22.208.3885: tcp 0
13:48:49.742456 IP 148.63.127.226.53734 > 176.79.22.208.443: tcp 0
13:48:49.742698 IP 176.79.22.208.443 > 148.63.127.226.53734: tcp 0
13:48:49.742820 IP 148.63.127.226.63748 > 176.79.22.208.443: tcp 0
13:48:49.742968 IP 176.79.22.208.443 > 148.63.127.226.63748: tcp 0
13:48:50.286313 IP 93.179.107.198.59665 > 176.79.22.208.445: tcp 0
13:48:50.756705 IP 148.63.127.226.63748 > 176.79.22.208.443: tcp 0
13:48:50.756823 IP 148.63.127.226.53734 > 176.79.22.208.443: tcp 0
13:48:50.756937 IP 176.79.22.208.443 > 148.63.127.226.63748: tcp 0
13:48:50.757042 IP 176.79.22.208.443 > 148.63.127.226.53734: tcp 0
13:48:51.120885 IP 79.124.62.74.8080 > 176.79.22.208.6624: tcp 0
13:48:51.845747 IP 79.124.62.74.8080 > 176.79.22.208.6777: tcp 0
13:48:51.929615 IP 79.124.62.98.8080 > 176.79.22.208.34089: tcp 0
13:48:52.768718 IP 148.63.127.226.53734 > 176.79.22.208.443: tcp 0
13:48:52.768932 IP 176.79.22.208.443 > 148.63.127.226.53734: tcp 0
13:48:52.769058 IP 148.63.127.226.63748 > 176.79.22.208.443: tcp 0
13:48:52.769231 IP 176.79.22.208.443 > 148.63.127.226.63748: tcp 0
13:48:54.755034 ARP, Request who-has 176.79.22.1 tell 176.79.22.208, length 46
13:48:54.755935 ARP, Reply 176.79.22.1 is-at 00:03:fa:00:00:01, length 46
13:48:55.812727 IP 79.124.62.98.8080 > 176.79.22.208.24049: tcp 0
13:48:56.781457 IP 148.63.127.226.63748 > 176.79.22.208.443: tcp 0
13:48:56.781697 IP 176.79.22.208.443 > 148.63.127.226.63748: tcp 0
13:48:56.781726 IP 148.63.127.226.53734 > 176.79.22.208.443: tcp 0
13:48:56.781984 IP 176.79.22.208.443 > 148.63.127.226.53734: tcp 0
13:49:02.605122 IP 79.124.62.98.8080 > 176.79.22.208.31045: tcp 0
13:49:04.793960 IP 148.63.127.226.53734 > 176.79.22.208.443: tcp 0
13:49:04.794003 IP 148.63.127.226.63748 > 176.79.22.208.443: tcp 0
13:49:04.794221 IP 176.79.22.208.443 > 148.63.127.226.53734: tcp 0
13:49:04.794311 IP 176.79.22.208.443 > 148.63.127.226.63748: tcp 0
13:49:06.282424 IP 79.124.62.98.8080 > 176.79.22.208.9534: tcp 0
13:49:08.167022 IP 79.124.62.98.8080 > 176.79.22.208.22083: tcp 0
13:49:10.812237 IP 79.124.62.74.8080 > 176.79.22.208.5472: tcp 0 -
@s_serra said in Get public ip for pcs:
00:03:fa:00:00:01
Really? What are the odds of that? But looks arp is working..
-
Do you know why the doors are not open to the outside? I already have my head in water :(
-
Mmm, you can see it's replying and that traffic is leaving the pfSense WAN.
Assuming you opened it to everywhere, as your rules showed above, I am not seeing any reply packets if I test from here.
So either something is blocking the replies upstream or the replies are going to wrong place.Increase the view detail in the pcap and make sure the MAC addresses are correct on those packets.
Steve
-
I had turned off the server
then everything was open.
I asked a colleague of mine to ping the ip 176.79.22.208 and he can't. on ip 176.79.20.129 which is the ip wan of pfsense it gets. it's a bit weird
-
@s_serra So if I traceroute to that IP.. Looks like it dies at what should be your gateway.
$ tracert -d 176.79.22.208 Tracing route to 176.79.22.208 over a maximum of 30 hops 1 <1 ms <1 ms 1 ms 192.168.9.253 2 18 ms 13 ms 11 ms 50.4.135.1 3 9 ms 11 ms 9 ms 76.73.191.106 4 10 ms 14 ms 9 ms 76.73.164.121 5 12 ms 11 ms 12 ms 74.199.91.22 6 29 ms 20 ms 21 ms 24.214.131.161 7 20 ms 20 ms 29 ms 24.192.154.220 8 39 ms 32 ms 31 ms 69.73.2.4 9 32 ms 35 ms 31 ms 75.76.35.13 10 32 ms 30 ms 31 ms 206.126.236.37 11 31 ms 30 ms 32 ms 72.52.92.226 12 35 ms 47 ms 34 ms 184.105.64.122 13 114 ms 101 ms 99 ms 184.104.197.74 14 * 114 ms 107 ms 184.104.196.161 15 117 ms 118 ms 113 ms 184.104.193.150 16 123 ms 119 ms 122 ms 184.104.204.234 17 126 ms 121 ms 137 ms 195.8.0.158 18 * * 123 ms 195.8.30.246 19 118 ms 117 ms 116 ms 176.79.22.1 20 * * * Request timed out. 21 * * * Request timed out. 22 * * * Request timed out.19 118 ms 117 ms 116 ms 176.79.22.1
You really need to sniff on your wan when someone is say trying to ping you - if you don't see the traffic hit pfsense.. Well then no its not going to work. no matter what you do on pfsense.
-
I'm still a noob.
How can I sniff out wan's traffic?
my pfsense gateway is 176.79.20.1. Do I have to add more gateways to pfsense for the other subnets to communicate?
-
@s_serra said in Get public ip for pcs:
my pfsense gateway is 176.79.20.1
Not for that IP range it isn't - your device since its getting its IP from dhcp, should get an gateway in its network. I take its that serra box.. look at a netstat -r to see what its default route is (ie its gateway)
example here is linux box on one of my vlans..
pi@ntp:~ $ netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 192.168.3.253 0.0.0.0 UG 0 0 0 eth0 192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 pi@ntp:~ $As to how to sniff. Under diagnostic menu on pfsense, packet capture.
You prob want to do that sniff in promiscuous mode - since the traffic towards 22.208 box is not pfsense network..
-
-
sure looks like the 22.1 address I said.. do -rn the n disables name resolution. So just see the IP.
You would keep it running until someone pings you.. I just did so you should see ping requests. I can pm you the address would of come from
-
-
@s_serra yup like I said 22.1 would be that devices gateway, which is last hop I see in my traceroute.. So I am getting there.. Now your sniff should of shown you my ping attempt.
