It happens that I participate in a bug hunting program and analyzing the app I realized that there is a particular parameter that is very important for access control and that only changes with the IP address.

Anyway, the question here is if I can set a specific public IP address. I don't need to receive a response, just issue a request to parse the request.

  • Great question! I would love to see a canonical answer to how the TCP/IP stack determines the IP address of the client, and whether that is spoofable. – Mike Ounsworth Feb 23 at 15:05
  • 38
    @MikeOunsworth You can spoof whatever you like at the host level. Convincing the rest of the network to go along with it is the hard part. – gowenfawr Feb 23 at 15:29
  • 1
    Are you in control of the server that hosts the app? If yes, then you can setup a VPN between the client and the server, and use any IP address you want inside the VPN. – user000001 Feb 24 at 7:16
  • "a bug hunting program".. if this was some sort of competition, you might try testing whether the machine that has this special IP is running some sort of proxy that you need to find out how to use. if this is just software analysis for a job, this fact should be mentioned in the final report, as hardcoding IPs for special access in an app is generally considered a bad move. – WooShell Feb 24 at 14:48

You can send out a packet with whatever IP address you like.

Then, one of the routers along the way might decide the packet makes no sense (it is a "martian packet") and discard it. Consider this:

                                 +------------------- GW4
             +----------------- GW2------+
             |              |
      +---- GW1 -----+             ---- GW3 ----
      |              |
     YOU           ALICE

You send out a packet with a source address of and directed to, say, GW1, serving your network which is, only expected to receive packets matching, and your packet doesn't match, so it is dropped. You could spoof a connection coming from your "neighbour" Alice, but no more.

Even if GW1 did not complain, it would forward the packet to the next hop, which serves the whole branch and also would ignore your packet.

And so on and so forth (the IP I used are actually not all that routable, but it's an example).

Granted, many routers won't do "ingress filtering" because they'll be obsolete or will believe it unnecessary and not cost-effective. But it only takes one hop to wreck the transmission.

Even without this hurdle, the difficulties are not over, because let's say you succeed in delivering to your target a packet coming from The target will reply -- and will reply to, so the reply packet will never get back to you. Indeed, should the reply packet arrive to, the latter would simply reset the connection as unsolicited.

This is a problem, because most protocols where you "only need to issue a request" are in fact sent over TCP, which requires a handshake between the communicating parties before any data can be sent. The major exception is HTTP/2,

And without that first reply packet you have precious little chance (not the same as zero chances, but still) of establishing a full TCP connection, without which you probably won't be able to send your request.

You might be able to do this using UDP, or other protocols which have no handshake, if the target application uses UDP (it probably doesn't).

  • 3
    Ingress filtering, not egress. – jcaron Feb 24 at 0:42
  • 3
    @jcaron this answer describes packets being filtered on the way out of network, so egress is correct – Fred Stark Feb 24 at 2:56
  • 4
    Ingress v egress is based on the interface where the filter is applied, i.e. on the interface where it enters the router (coming from the customer) or on the one where it exits the router (towards the Internet, so already mixed with traffic from other customers). I believe the filtering is usually done on the interface which receives the traffic (on the customer side), and that is were you can have the most accurate filtering, otherwise you can allow people to spoof IPs of other customers of the same ISP. Of course you can do either, or both, but ingress is more efficient (and often simpler). – jcaron Feb 24 at 9:08
  • 11
    While the answer describes packets exiting the network, the check is done when they arrive. So @jcaron has the right of it - it's ingress filtering, not egress. – LSerni Feb 24 at 9:45
  • 3
    HTTP/2 is also going over TCP (and usually TLS). The point of HTTP/2 is to have multiple request-response pairs in the same TCP connection (and even in parallel), but it's still TCP. You might be thinking of HTTP/3, which is using QUIC over UDP (and doesn't have an RFC yet). – Paŭlo Ebermann Feb 24 at 21:58

Probably not, depending upon whether or not your ISP is implementing Ingress Filtering:

a technique used to ensure that incoming packets are actually from the networks from which they claim to originate.

If your ISP is implementing Ingress Filtering, then your forged packets will be dropped as they traverse your ISP's network, and will never reach your target.

The odds are that your ISP does implement it:

As of 2012, one report suggests that, contrary to general opinion about the lack of BCP 38 deployment, some 80% of the Internet (by various measures) were already applying anti-spoofing packet filtering in their networks.

  • 1
    Note that the 20% if the networks that weren't checking in 2012 were counting on the other 80% for anti-spoofing measures. Most networks without this ability would only be spoofed with comms through their network only. But this is 2021 and this issue doesn't exist or it could easily be used now to divert traffic and could take down providers. – blankip Feb 24 at 20:35

Even in the absence of ingress filtering as described in the other answers, IP spoofing will hit another hurdle: the TCP 3-way handshake, and possibly higher-level handshakes.

TCP is the basis for many of the most common protocols, including HTTP, FTP, SMTP, POP3, IMAP and their TLS-secured counterparts, as well as SSH, and many many more.

When you attempt a TCP connection, you send a first packet (SYN). Server replies with SYN-ACK. Client sends ACK. During the SYN and SYN-ACK exchange, random sequence numbers are chosen and transmitted.

If you use a spoofed IP address, the server will send the SYN-ACK to the device which actually has that IP, not you. So you won't receive the server's sequence number, and no communication will be possible.

There used to be issues a few eons ago when the sequence numbers were predictable. That allowed you to send packets blindly on the TCP connection (you would not receive any answer, but you could still send requests). This should now be fixed everywhere (see RFC1948).

If somehow you still manage to do so, most protocols now use TLS on top of TCP, which adds yet another handshake which will very definitively prevent you from sending anything if you don't receive the return traffic.

The story is different for UDP and raw IP protocols, but those have more limited use.


If access control is done in the application layer and it's a HTTP-based application, you might be able to bypass the check by forging the relevant HTTP headers (e.g. X-Forwarded-For, True-Client-IP, or X-Real-IP).


Your public IP address, if issued dynamically, cannot be switched until your ISP decides to. Static IP addresses assigned by your ISP can be switched, but your internet connection won't work unless the specific IP address has been assigned to you and in your IP range/scope.


  • dynamic IP addresses typically are issued using consumer products.
  • static IP addresses are usually assigned to commercial/business products.

So, can you change your public IP address to a specific one?
Yes, and a working internet connection will reside only if you own that IP address and it is in your IP scope/range.

Thanks for covering the TCP-IP basics with us this morning.

New contributor
Stereomac is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.

I think we might be overcomplicating things. If it does not have to be a specific hard-coded value, just use another endpoint.

Of course, if you are a well-funded developer you can build a testbed independently of the internet (your own internet) and re-use public addresses. If you only need different values, you can have multiple IP addresses on the same host, but likely similar.

Consider VPN, VLAN, and VM's, even cloud. Also out of band such as GSM.

Are you filtering with IPTables/Apache2 directives or similar that rely upon any kind of reverse DNS? This will be extra work but bread and butter type work. It may be as simple as configuration management of dev and prod files.

  • "bug bounty" implies that the OP is a 3rd party to the system under evaluation. Which would appear to defeat all of your suggestions. – schroeder yesterday
  • But they get to analyze the app. which external bug bounty hunters cannot do. Supposedly they could compromise the genuine end points (physically a la Mission Impossible), or the white list as an insider. Of course many genuine insiders don't get to see the back doors either. – mckenzm yesterday

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.