Get public ip for pcs

s_serra

    79.124.62.98.8080 > 176.79.22.208.9555: Flags [S], cksum 0xdf92 (correct), seq 1968946451, win 1024, length 0
00:04:17.625248 00:e2:69:43:3d:a8 > 00:03:fa:00:00:01, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40, bad cksum 0 (->e5d2)!)
    176.79.22.208.9555 > 79.124.62.98.8080: Flags [R.], cksum 0xe37f (correct), seq 0, ack 1968946452, win 0, length 0
00:04:22.741602 08:00:27:ed:96:55 > 00:03:fa:00:00:01, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 176.79.22.1 tell 176.79.22.208, length 46
00:04:22.742483 00:03:fa:00:00:01 > 08:00:27:ed:96:55, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 176.79.22.1 is-at 00:03:fa:00:00:01, length 46
00:04:26.657923 00:03:fa:00:00:01 > 08:00:27:ed:96:55, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 247, id 41561, offset 0, flags [none], proto TCP (6), length 40)
    79.124.62.98.8080 > 176.79.22.208.41109: Flags [S], cksum 0xf784 (correct), seq 2334004252, win 1024, length 0
00:04:26.658141 00:e2:69:43:3d:a8 > 00:03:fa:00:00:01, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40, bad cksum 0 (->e5d2)!)
    176.79.22.208.41109 > 79.124.62.98.8080: Flags [R.], cksum 0xfb71 (correct), seq 0, ack 2334004253, win 0, length 0
00:04:30.270828 00:03:fa:00:00:01 > 08:00:27:ed:96:55, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 247, id 16175, offset 0, flags [none], proto TCP (6), length 40)
    79.124.62.74.8080 > 176.79.22.208.2227: Flags [S], cksum 0x9731 (correct), seq 1983652172, win 1024, length 0
00:04:30.271106 00:e2:69:43:3d:a8 > 00:03:fa:00:00:01, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40, bad cksum 0 (->e5ea)!)
    176.79.22.208.2227 > 79.124.62.74.8080: Flags [R.], cksum 0x9b1e (correct), seq 0, ack 1983652173, win 0, length 0

johnpoz

@s_serra said in Get public ip for pcs:

176.79.22.208.9555 > 79.124.62.98.8080: Flags [R.],

Well that is a RST.. .208 telling him to F off..

that traffic looks OFF.. Why would source traffic come from 8080 trying to do a syn to random ports?

johnpoz

Where exactly were you sniffing. I logged into your pfsense. And trying to ping your 22.208 address from MY ip.. I saw no traffic sniffing going to your wan for the 22.208 address.

s_serra

@johnpoz I'm sorry but I went to sleep and turned off the computer. It's online now. When you can, you can test.

s_serra

@johnpoz said in Get public ip for pcs:

Why would source traffic come from 8080 trying to do a syn to random ports?

I don't know hahaha

I have no control over this ip: 79.124.62.98

s_serra

This post is deleted!

stephenw10

Ok, well this was bizarre!

The root of the issue here was that the default 'reply-to' setting on the WAN firewall rule (because it's dhcp with a gateway) was somehow causing pf to send reply traffic using it's own MAC address. Which the ISP was likely legitimately dropping.

Disabling 'reply-to' allowed the traffic to pass without pf interfering.

Quite how that's possible is something we're looking at now.

If the bridge interface had the dhcp address and gateway on it and neither WAN or LAN have an address you would not not this though. That is the expected way to setup something like this.

Steve

johnpoz

@stephenw10 said in Get public ip for pcs:

Disabling 'reply-to' allowed the traffic to pass without pf interfering.

So your saying he is working now - because I am not able to ping that IP currently. Or you duplicated this in lab?

stephenw10

It is (was) working as expected for him but I think he disconnected the target and, hopefully, set some more restrictive rules.

johnpoz

@stephenw10 ah - ok, yeah he had sent me the login and that is no longer working. So glad its fixed and yeah hope set some more restrictive rules ;)

s_serra

yes it was working I now turned off the server for testing and put stricter firewall rules. Thanks a lot for the help. I was never going to get there alone. Hahahaha

johnpoz

For future reference - could of spotted this problem right away by looking on the sniff when reply traffic went out the wan. Validating the mac address on the outgoing traffic.