I'm looking for a while for a solution to see the original source IP from the connected client, but couldn't find any.
Situation: I've for example an TCP forwarder for SMTP, IMAP etc. to my backend. Goinging through an newt site.
For sure I wanna block malicious clients via fail2ban, doing for example relay tries.
BUT I only can see the newt "coordinators" IP.
Is there a way to solve it? I thought, with RAW TCP, I could achieve this.
Thanks a lot!
M0nk3y
Originally created by @M0nk3yOo on GitHub (May 20, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/753
Dear community,
I'm looking for a while for a solution to see the original source IP from the connected client, but couldn't find any.
Situation: I've for example an TCP forwarder for SMTP, IMAP etc. to my backend. Goinging through an newt site.
For sure I wanna block malicious clients via fail2ban, doing for example relay tries.
BUT I only can see the newt "coordinators" IP.
Is there a way to solve it? I thought, with RAW TCP, I could achieve this.
Thanks a lot!
M0nk3y
@oschwartz10612 commented on GitHub (May 22, 2025):
Hi!
With raw TCP resources you can not know the client IP downstream behind newt unless you use the proxy protocol. But if you want to use fail2ban I think this could be installed on the Pangolin side before it goes down the tunnel. Would this work for you?
<!-- gh-comment-id:2899916583 -->
@oschwartz10612 commented on GitHub (May 22, 2025):
Hi!
With raw TCP resources you can not know the client IP downstream behind newt unless you use the proxy protocol. But if you want to use fail2ban I think this could be installed on the Pangolin side before it goes down the tunnel. Would this work for you?
What do you mean with "proxy protocol", web protocols http/https? Or is there any other setting to achive this? If so, I'll be happy with any hint :-)
fail2ban on Pangolin side might not be sufficient, because the mail server will check his own logs to decide if the connected client needs to blocked or not. For example if he/she/it has several bad login tries, or tries to relay spam mails through my server.
Best
M0nk3y
<!-- gh-comment-id:2900016623 -->
@M0nk3yOo commented on GitHub (May 22, 2025):
Hi,
thanks for your reply! :-)
What do you mean with "proxy protocol", web protocols http/https? Or is there any other setting to achive this? If so, I'll be happy with any hint :-)
fail2ban on Pangolin side might not be sufficient, because the mail server will check his own logs to decide if the connected client needs to blocked or not. For example if he/she/it has several bad login tries, or tries to relay spam mails through my server.
Best
M0nk3y
It seems what you are looking for is to capture the original IP in order to use fail2ban on your mail server that is behind the proxy. If this is the case, you need to configure your mail server (ie postfix, dovecot, etc) to log the FOREWARDED IP. You'll need to consult the documentation for your backend (you don't specify it). Fail2ban examines the logs, so making sure that your application that is writing the logs is logging the correct address is missing piece.
<!-- gh-comment-id:2904948914 -->
@kalikid021 commented on GitHub (May 23, 2025):
It seems what you are looking for is to capture the original IP in order to use fail2ban on your mail server that is behind the proxy. If this is the case, you need to configure your mail server (ie postfix, dovecot, etc) to log the FOREWARDED IP. You'll need to consult the documentation for your backend (you don't specify it). Fail2ban examines the logs, so making sure that your application that is writing the logs is logging the correct address is missing piece.
@oschwartz10612 commented on GitHub (May 24, 2025):
proxy protocol is a mechanism that preserves a client's original IP address when a connection passes through a proxy server or load balancer. Without this protocol, the server would only see the proxy's IP address.
Pangolin does not have great support for enabling this and stuff for resources which we need to do better about but you would need to make sure downstream is aware of the ip.
I think unfortunately this is an area we need to improve on and I dont know if you can get this functionality easily right now.
<!-- gh-comment-id:2906349974 -->
@oschwartz10612 commented on GitHub (May 24, 2025):
proxy protocol is a mechanism that preserves a client's original IP address when a connection passes through a proxy server or load balancer. Without this protocol, the server would only see the proxy's IP address.
Pangolin does not have great support for enabling this and stuff for resources which we need to do better about but you would need to make sure downstream is aware of the ip.
I think unfortunately this is an area we need to improve on and I dont know if you can get this functionality easily right now.
@github-actions[bot] commented on GitHub (Jun 8, 2025):
This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.
<!-- gh-comment-id:2953296346 -->
@github-actions[bot] commented on GitHub (Jun 8, 2025):
This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.
@github-actions[bot] commented on GitHub (Jun 22, 2025):
This issue has been automatically closed due to inactivity. If you believe this is still relevant, please open a new issue with up-to-date information.
<!-- gh-comment-id:2993839511 -->
@github-actions[bot] commented on GitHub (Jun 22, 2025):
This issue has been automatically closed due to inactivity. If you believe this is still relevant, please open a new issue with up-to-date information.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @M0nk3yOo on GitHub (May 20, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/753
Dear community,
I'm looking for a while for a solution to see the original source IP from the connected client, but couldn't find any.
Situation: I've for example an TCP forwarder for SMTP, IMAP etc. to my backend. Goinging through an newt site.
For sure I wanna block malicious clients via fail2ban, doing for example relay tries.
BUT I only can see the newt "coordinators" IP.
Is there a way to solve it? I thought, with RAW TCP, I could achieve this.
Thanks a lot!
M0nk3y
@oschwartz10612 commented on GitHub (May 22, 2025):
Hi!
With raw TCP resources you can not know the client IP downstream behind newt unless you use the proxy protocol. But if you want to use fail2ban I think this could be installed on the Pangolin side before it goes down the tunnel. Would this work for you?
@M0nk3yOo commented on GitHub (May 22, 2025):
Hi,
thanks for your reply! :-)
What do you mean with "proxy protocol", web protocols http/https? Or is there any other setting to achive this? If so, I'll be happy with any hint :-)
fail2ban on Pangolin side might not be sufficient, because the mail server will check his own logs to decide if the connected client needs to blocked or not. For example if he/she/it has several bad login tries, or tries to relay spam mails through my server.
Best
M0nk3y
@kalikid021 commented on GitHub (May 23, 2025):
It seems what you are looking for is to capture the original IP in order to use fail2ban on your mail server that is behind the proxy. If this is the case, you need to configure your mail server (ie postfix, dovecot, etc) to log the FOREWARDED IP. You'll need to consult the documentation for your backend (you don't specify it). Fail2ban examines the logs, so making sure that your application that is writing the logs is logging the correct address is missing piece.
@oschwartz10612 commented on GitHub (May 24, 2025):
proxy protocol is a mechanism that preserves a client's original IP address when a connection passes through a proxy server or load balancer. Without this protocol, the server would only see the proxy's IP address.
Pangolin does not have great support for enabling this and stuff for resources which we need to do better about but you would need to make sure downstream is aware of the ip.
I think unfortunately this is an area we need to improve on and I dont know if you can get this functionality easily right now.
@github-actions[bot] commented on GitHub (Jun 8, 2025):
This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.
@github-actions[bot] commented on GitHub (Jun 22, 2025):
This issue has been automatically closed due to inactivity. If you believe this is still relevant, please open a new issue with up-to-date information.